bug-inetutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: next steps for inetutils?


From: Simon Josefsson
Subject: Re: next steps for inetutils?
Date: Wed, 10 Feb 2021 10:46:53 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

ams@gnu.org (Alfred M. Szmidt) writes:

>    * arp tool
>
>    * nc (netcat) tool
>
> I like these additions, but I am worried about compatibility against
> the more prolific versions of those tools.

Agreed, an analysis of existing implementations and their differences
would be useful.  This applies to some of our other tools too, like
traceroute where other implementations have slightly different
behaviour.

>    * fix all warnings with autoconf 2.71 - I didn't want to touch this
>      before 2.0 since we had succesful build reports, but there are plenty
>      of old m4 constructs that we should use gnulib tools for instead.
>
>    * use gitlog-to-changelog instead of manual ChangeLog entries
>
> I'm sorta still against it -- since it would ruin my work flow of
> being able to edit the ChangeLog file post-factum.  But I am sure I
> can be convinced without much work ... if someone else does the
> work. :-)

Modifying the ChangeLog that ends up in tarballs is possible, see how
coreutils is doing it.  Many GNU projects appears to be moving this way
already.

>    * Enhance Man pages so they fully supersede NetKit and BSD man pages
>
> Can you elaboraet a bit?

There is text in the traditional NetKit/BSD man pages that isn't in our
man pages.  I am hoping it is at least in our info manual (but I'm not
sure), and it would be nice to review if there is anything that makes
sense to put in the man pages.  Given that NetKit is not maintained, I'm
not sure there are any maintained man pages for some of the ancient
tools anywhere, it would be nice if Inetutils would become the canonical
place for this too -- almost all GNU distributions ship the older man
pages.

>    * generally use gnulib for portability more than we use today.
>
> Yes, yes, yes, pelase.
>
>    * Mingw/cygwin support?
>
> If it is not much work, why not ...
>
>    * Remove Kerberos V4 support?  I'm not sure there are any usable
>      Kerberos V4 implementations around anymore, and it is is
>      single-DES-only so they are completely insecure anyway.
>
> Sounds like a good idea.

Let me add:

* setuid-less ping, ping6 and traceroute

* merge ping and ping6 into one binary?  ping6 should mean 'ping -6'.
  There is code duplication between the tools now, and the semantics of
  the tools is slowly diverging.

/Simon

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]