[arch-dev-public] [signoff] net-tools-1.60.20110819cvs-1 and inetutils-1.8-4

Eric Bélanger snowmaniscool at gmail.com
Fri Aug 19 18:18:02 EDT 2011


On Fri, Aug 19, 2011 at 5:38 PM, Dave Reisner <d at falconindy.com> wrote:
> On Fri, Aug 19, 2011 at 05:29:06PM -0400, Eric Bélanger wrote:
>> Hi,
>>
>> Following discussions between a few of us on IRC and private emails,
>> we decided to remove the hostname binary from the net-tools package
>> and to replace it by the one from inetutils. Unlike the hostname from
>> coreutils, the inetutils hostname has all the functionnality of the
>> net-tools' one. I've also added scripts which implements the behaviour
>> of the  domainname and dnsdomainname symlinks that were in the
>> net-tools package so everything should work as before. If not, let us
>> know. I've also added inetutils to the base group as many apps expect
>> hostname to be installed (I think its also a standard).
>>
>> The net-tools package also had other changes as followed:
>>
>> - update to current upstream cvs
>> - remove hostname (and the symlinks to it, dnsdomain and domainname)
>> as well as manpages related to it
>> - changed license to gpl2
>> - removed !makeflags from options (seems to work fine without it,
>> except for some extra compile time warnings).
>>
>>
>>
>> Eric
>
> Two minor nitpicks about the wrapper scripts:
>
> 1) It would probably be worthwhile to hardcode the path to the inetutils
> hostname binary.
> 2) exec $path/hostname, in both cases, will save an extra fork in invocation.
>
> Also, do we want to add manpage symlinks for {dns,}domainname? It's not
> entirely the truth, so I'm not convinced we want this.
>
> dave
>

I could do these 2 changes to the scripts.  The current net-tools in
core has {dns,}domainname man pages symlinks to hostname so I guess we
might as well add them. I'll wait for more opinions before doing these
changes in case there's another issue.

Eric


More information about the arch-dev-public mailing list