On Thu, Jun 9, 2011 at 10:38 PM, Eric Bélanger <[email protected]> wrote: > On Thu, Jun 9, 2011 at 4:15 PM, Tom Gundersen <[email protected]> wrote: >> Hi Eric, >> >> On Thu, Jun 9, 2011 at 10:06 PM, Eric Bélanger <[email protected]> >> wrote: >>> Also, inetutils also could provide a hostname and even an ifconfig >>> binary. They are currently not included in the package as they are (or >>> were) provided by other packages. See the list of utilities that we >>> could add in inetutils: >>> >>> --disable-tftp --disable-tftpd \ >>> --disable-ping --disable-ping6 \ >>> --disable-logger --disable-syslogd \ >>> --disable-inetd --disable-whois \ >>> --disable-uucpd --disable-hostname \ >>> --disable-ifconfig --disable-traceroute >>> >>> I don't know how they compare to the other versions of these tools >>> provided by net-tools, coreutils, etc. But they might be a good >>> alternative. >> >> That's probably a very good idea. We'd just have to check the >> functionality versus net-tools. >> >> The question remains: what to do with initscripts. It just needs to >> set the hostname, seems silly to pull in net-tools or inetutils just >> for this... >> > > What you suggested above seems right: have initscripts provide it's > copy of hostname. The package is already arch dependent because of the > minilogd binary so adding another binary doesn't change anything. And > at 22KB, hostname is quite small so we don't wast much of diskspace. > > The other solution is what we do now: have hostname in a base package > that everyone has installed like coreutils.
Hm, ok I'll go back to my original suggestion then. Have a hostname just for initscripts and let people install net-tool (or inetutils if that's better) to get the normal functionality back. Though the initscripts specific hostname should still be shipped with coreutils I think, just moved to /lib/initscripts, so only initscripts will know about it ;-) That makes packaging easier (I think). -t
