FS#24647 - [net-tools] behavior change of hostname, and missing dnsdomainname
Attached to Project:
Arch Linux
Opened by Ivan Todoroski (Grnch) - Thursday, 09 June 2011, 12:04 GMT
Last edited by Tom Gundersen (tomegun) - Thursday, 09 June 2011, 15:49 GMT
Opened by Ivan Todoroski (Grnch) - Thursday, 09 June 2011, 12:04 GMT
Last edited by Tom Gundersen (tomegun) - Thursday, 09 June 2011, 15:49 GMT
|
Details
[Rephrased by tomegun:]
After the move of hostname/domainname to coreutils/yp-tools the following bugs occur: - dnsdomainname is nowhere to be found - hostname does not support the -f parameter (used for getting the fully qualified domain name) |
This task depends upon
Closed by Tom Gundersen (tomegun)
Thursday, 09 June 2011, 15:49 GMT
Reason for closing: Fixed
Additional comments about closing: Fix for dnsdomainname in [testing]. For the hostname issue, open a new bug as this is to littered with irrelevant stuff.
Thursday, 09 June 2011, 15:49 GMT
Reason for closing: Fixed
Additional comments about closing: Fix for dnsdomainname in [testing]. For the hostname issue, open a new bug as this is to littered with irrelevant stuff.
dnsdomainname is provided by yp-tools, not coreutils (see the http://www.archlinux.org/).
If you have a suggestion for versions of these tools that are better than what we provide, and still maintained, feel free to suggest them.
That said, as a matter of principle, I don't spend more than five seconds dealing with bug reports containing phrases like "what the hell?!", so if you have further questions you'd have to ask someone else.
The phrase "what the hell" was utterred in momentary frustration, but it was more than justified considering that you broke a major package at the core of the system without warning. If yp-tools must now be installed to retain the same functionality (dnsdomainname), you could have at least added a courtesy dependency on yp-tools to the net-tools package in order to ease the transition, or at the very least printed a warning message about the change during net-tools package installation, which is what other packages do when there is some important change in a new version.
I could understand this kind of silent and abrupt change if it was some peripheral package, but in case of a core part of the system I'm sure there are ways the transition could have been handled smoother and more thoughtful.
If you are going to act like a primadonna and refuse to answer the questions of users whose systems you broke and who got understandably (and briefly) pissed off about it, then you are not fit to be a maintaner of such core packages. Please check your ego at the door and consider the higher goals of Arch Linux, which is to provide a good, stable and simple distribution for everyone.
This type of careless patching of core packages is exactly what drove me away from Gentoo.
http://www.archlinux.org/news/deprecation-of-net-tools/
If there were such a warning, there would have been no frustration. I would immediately know what to do instead of wondering why a bunch scripts stopped working, and this bug report probably wouldn't have been filed at all.
net-tools: legacy network support
That should prompt you to look deeper into the matter but indeed it could be phrased better.
imo old tools shouldn't be removed unless it has a name clash. dnsdomainname should be bring back since it doesn't clash with anything even if it has a replacement from yp-tools
"New optional dependencies for initscripts
net-tools: legacy network support"
Yeah, right... that's very obvious. Sorry, vague mentions in unrelated packages are useless. I would have never connected the problem to that message in a million years, until I went through the trouble of debugging it myself.
However, the comment I eventually found in net-tools/PKGBUILD explicitly spelled out the change, and that's the type of warning that should have been explicitly output during installation.
But it wasn't.
And that's a problem.
Plus, there is still the question of the missing -f parameter to hostname. What do we about that? It's a gratuitous incompatibility with all the major Linux distros (RedHat, SuSE, Debian, Ubuntu).
Was the "elegance" of not relying on old tools really worth the breakage and incompatibility with other major distros?
initscripts needs "hostname" and don't want to rely on net-tools
yp-tools needs "nisdomainname" and don't want to rely on net-tools
We solved this now by moving ypdomainname/nisdomainname/domainname (which are all links to the same binary) to yp-tools (not sure what happened to dnsdomainname, I have asked the packager, probably a bug), and moving hostname to coreutils.
As I said before: feel free to suggest a better solution, within these constraints. I'm assigning this bug to the relevant packagers so they can have a look. I will also take the liberty of rephrasing your report, this way it should be more that people will spend time on it.
Did you check how the other distro's do this in their most recent releases? I just had a quick look now at Fedora: <http://pkgs.fedoraproject.org/gitweb/?p=coreutils.git;a=blob;f=coreutils.spec;h=729c14943cca283310655b717d9863c37e5931d0;hb=HEAD>. Looks like they use the hostname from coreutils.
It would be helpful if you check what SuSE, Debian and Ubuntu do as well, if you have not already done so, and provide links to their package sources.
Description:
Guys, what the hell? The latest net-tools update completely broke hostname/dnsdomainname. I see the PKGBUILD contains a comment that they are now provided by coreutils, but that's just not true:
- dnsdomainname is nowhere to be found in coreutils
- hostname from coreutils is very basic and doesn't support the -f parameter for getting the fully qualified hostname of the machine
What this means is that you are left with no way of determining the fully qualified hostname of an Arch box! As things currently stand, neither `hostname -f` nor `hostname`.`dnsdomainname` work.
This caused all kinds of scripts to fail on my build box for work.
Please be more careful when ripping out files from core packages...
Additional info:
* package version(s)
net-tools 1.60-16
coreutils 8.12-2
Steps to reproduce:
[root@buildbox ~]# pacman -Syu
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
:: Starting full system upgrade...
there is nothing to do
[root@buildbox ~]# hostname -f
hostname: invalid option -- 'f'
Try `hostname --help' for more information.
[root@buildbox ~]# dnsdomainname
-bash: dnsdomainname: command not found
Thanks for the acknowledging the problem, and thanks for the hint about Fedora. We are actually using the enterprise version of RedHat where this change hasn't trickled in yet. I will check the other distros and let you know.
In fact, I would urge you to push out an immediate update to net-tools that just adds this warning, so that other users at least have a fair warning before they fall in the same trap as me.
I think "domainname" relies on explicitly setting the domain name using yp-tools or in some config file, whereas "dnsdomainname" actually looks up the current domain name of the machine from DNS or /etc/hosts. I believe that's a significant change in functionality, therefore "domainname" is not a suitable replacement for "dnsdomainname".
I don't understand this apparent resistance to simply printing a warning about hostname/dnsdomainame during net-tools installation?
It can be something as short as: hostname and dnsdomainname have been removed from net-tools, please see http://www.archlinux.org/news/deprecation-of-net-tools/
Why is this such a problem?
I took a second look at the Fedora link you provided and in fact they DO NOT use hostname from coreutils. So Arch will indeed be incompatible with all major distros if it decides to use hostname from coreutils.
If you look further down in the Fedora coreutils.spec you will find this:
----------------------------
# These come from util-linux and/or procps.
for i in hostname uptime kill ; do
rm $RPM_BUILD_ROOT{%_bindir/$i,%_mandir/man1/$i.1}
done
---------------------------
So as you can see they in fact remove /bin/hostname from the coreutils build before packaging it, and they explicitly state that they expect "hostname" to be supplied by some other package.
Digging further, you will see that their "hostname" does not come from net-tools either:
http://pkgs.fedoraproject.org/gitweb/?p=net-tools.git;a=blob;f=net-tools.spec;h=3c0520e88fd325e993663cd0eb7be906019bd334;hb=HEAD
-------------------
#remove hostname (has its own package)
rm %{buildroot}/bin/dnsdomainname
rm %{buildroot}/bin/domainname
rm %{buildroot}/bin/hostname
rm %{buildroot}/bin/nisdomainname
rm %{buildroot}/bin/ypdomainname
------------------
As you can see, they expect all these hostname related tools to come from a third package called "hostname". Now if you look inside that package:
http://pkgs.fedoraproject.org/gitweb/?p=hostname.git;a=blob;f=hostname.spec;h=c80d2b05ee17d8dca948a447d1aaaec9f0ca59dc;hb=HEAD
you will see that its source code ultimately comes from Debian:
http://packages.qa.debian.org/h/hostname.html
I downloaded this Debian package and confirmed that the "hostname" command indeed supports the -f option, so it is functionally equivalent to the one from net-tools. In fact it's very likely that Debian took the hostname-related tools from net-tools and assigned someone to properly maintain them.
@Ivan: it is not a problem to print a warning. It is a judgement call when we package whether or not to do it (if we add too many people will not read them all). However, we _do_ expect people to follow the announcements, so complaining about this after the package has left [testing] is not very helpful.
What to do with hostname is still being discussed. Please open a new bug report if you want to track it, but this time please try to be concise and restrain yourself in your comments, as your flaming is deterring other devs from joining the discussion. We want to fix all bugs, just provide the technical details, and we will do our best.