Am 20.11.2012 12:00, schrieb Felipe Contreras:
Thomas Bächler wrote:
Am 20.11.2012 01:07, schrieb Kevin Chadwick:
Odd, my take was that the main goal was trying to bring back a separate /usr.
They believe that the problem is that udev refuses to work with /usr not mounted. They also believe the problem to be "solved" by just removing the test. They do not even remotely understand why separate /usr is broken,
This is not true. It might be broken for *some* setups, but not all.
Do you want me to point to the mails where Gentoo developers explain how a separate /usr works perfectly fine in *their* setup?
As a Linux distributor, you want to have a setup that works for all of your users. And in fact, I remember receiving many bug reports that library A and binary B needed to be in / instead of /usr. You'd end up patching Makefiles and moving files around, creating new bugs because you missed something. It was a workload that was not worth the gain at all. So you cannot simply consider what is needed for _your_ setup, but what is needed for _all_ setups. In addition, some bugs that occur are very subtle, so an ignorant developer may not even notice them, and thus consider them non-existent.
This is a hasty generalization fallacy; because a separate /usr is broken in some cases, doesn't mean it's broken in all cases.
If it's broken in any supported setup, it can be considered broken. You need to think globally - thinking about your single computer is ignorant, and you should not be developing a Linux distribution with such thinking.
Since Gentoo is all about choice, a package like udev should not break the setups that are already working.
That's Gentoo's problem. They refuse to do the right thing and mount /usr before switching from initramfs to real root.
and that "fixing" this problem eventually results in installing everything to / and leaving /usr mostly empty.
Wrong. Only the things that are needed at early boot, which are not that many.
And this is where you are wrong. Udev launches programs any time (in particular, on early boot) because certain devices appear. In the future, this will be done for more programs, not less. And every time such a rule is added, you need to move another program from /usr to /, because someone will report it as a bug. Now, you could rewrite udev to ignore those events and execute them later when /usr is mounted. The question you need to ask yourself is this: What is the gain, and what is the cost? The cost: udev becomes much more complex because it needs to store failed events and retry them later, which may lead to many more internal problems. This is a very high cost in terms of maintenance and code over-complication. What is the gain? You support a separation between / and /usr which serves no technical purpose and is not well-defined. So you do lots of work for nothing - when you just could have made sure everything is mounted and accessible before switching to the real root (which is easy to do, compared to everything I described above).
They also "fixed" udev by removing blkid support, although util-linux deprecated the "blkid -o udev" option a while ago.
And you think util-links is the only one that provides blkid?
What's this that I see in the corner of my eye?
http://git.busybox.net/busybox/tree/util-linux/blkid.c
That's right, and alternative implementation of blkid.
What you see in the corner of your eye is an implementation of blkid that a) is often behind the util-linux implementation when new file systems appear. b) never supported 'blkid -o udev', which udev relied on before it linked to libblkid. So, unless eudev reintroduces libblkid support, it will rely on util-linux versions older than 2.23, because that's when the udev-compatible output will be gone. This is another indication of how little these guys know about what's going on in the Linux ecosystem.
The general consensus seems to be that they have no idea what they are doing (see the statements of Greg K-H or Kay Sievers on the topic).
Oh, I wasn't aware that Greg K-H and Kay Sievers were the holders of The Truth.
They are just two of the people who know what's going on and have dealt with these topics for years. In contrast to the eudev people, they understand the problems and why particular choices were made.