On Fri, Aug 19, 2011 at 06:18:02PM -0400, Eric Bélanger wrote:
On Fri, Aug 19, 2011 at 5:38 PM, Dave Reisner <d@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
I'm also a little curious what happened to the whole idea of having a 'hostname' provider. We've (again) broken all tools that quietly depend on a hostname binary and were "fixed" to depend on net-tools. First of what could be many: https://bugs.archlinux.org/task/25681 dave