[arch-general] Gentoo udev fork w/o systemd

[Thomas Bächler]

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20121120/317dcb77/attachment-0001.asc>