[gentoo-dev] Re: Tightly-coupled core distro

[Steven J. Long]

On Sun, Nov 18, 2012 at 05:16:18PM +0200, Samuli Suominen wrote:
> I'm still happy enough with building udev out from systemd tree and
> letting sep. /usr consept from 90s to finally die in favour of
> simplifying the system.

 It's from a lot earlier than the 90s. Perhaps we should get rid of pipes,
too- they're /so/ 1970s.

 Torvalds expressed it well[1]:
  You made the statement that you want to get away from 30 years of
  history, but the fact is, "30 years of history" is a damn good argument
  for "that thing worked".

> The BIOSes have been upgraded last century to support booting from
> larger partitions, the need has long past.
> Nobody has ever provided a valid reason for using sep. /usr in the ML
> either.
>
 So at the same time as you have never heard a valid reason, the need (which
you have never understood) is long past? Pfft.

 To reiterate again: many of us are used to keeping /usr on a separate
partition for security and backup purposes (other use-cases for a separate
partition include mounting /usr over NFS, or a common partition for
virtual machines.) I'm sure other people would have more. Irrespective,
it should be about mechanism, not policy, and certainly not about breaking
existing setups.

 Many of the advertised benefits of the "merge /bin and /sbin to /usr"
concept are in fact just benefits of having a separate /usr partition,
though of course they're presented as new and unique to the merge. So, if
you accept those as benefits, you cannot logically deny them as benefits of
a traditional /usr split.

 Further, as one user pointed out[2]:
"I'd be more likely to just stick /usr back on / than create an initramfs
- it was only because the LVM guide recommended that /usr go on its own
partition that I now face this situation."

 We were given a simple requirement ages ago: udev requires /usr and
/var (and going forward may require /opt for 3rd party drivers) mounted
before it starts, not for udev itself but for helper scripts that it may
call. Why get bogged down in anything else?

 The recommended (which became "supported") method to do this was
to use an initramfs, since apparently any chicken-and-egg problems (such
as requiring a udev-initiated device to mount /usr) are easier to handle
there. (Note that no-one has ever provided a description of how they did
that, eg for their bluetooth keyboard, so that the issues, and how they
are addressed, could be made more transparent to everyone.)

 A few us are happily running initramfs-less machines by fulfilling the
requirement with a couple of patches to openrc initscripts[2]. (It's
been working fine here since last August.) This works in the case where
you didn't need an initramfs before, ie have modules for local-disks and
filesystems built-in, root not on LVM or encrypted, but other partitions
might be-- which includes LVM users who followed the Gentoo docs.

 If that's not enough, there is *already* a forked udev version which quite
a few users have been using[3] and reporting success with. I'd hope the
new fork would just collaborate with them, but it's entirely up to them
what they do.

 All of this argues that, irrespective of your views of the layouts admins
prefer to use, they will still use them regardless, and indeed users will
put in the work you yourself told them to.[4] I really don't understand
why people are getting beat up on, just for going ahead and doing what
they've been told to: provide code for an alternative.

 If a Gentoo developer doesn't understand what a Gentoo project means,
that's his problem. Nor should Gentoo projects suddenly change what they
are because "the internet" doesn't understand them. That's a ridiculous
basis for any change.

 The thing none of the proponents of an initramfs, with no other support
for a separate /usr (apart from busybox sep /usr which does NOT fulfil the
requirements presented by Chainsaw, which Council voted to approve before:
for a start it doesn't handle /usr on LVM), have ever answered is:

 How do you deal with the mismatch problem?

 That is, when you have programs or libs upgraded, just as part of normal
system upgrades, and they are now different, potentially incompatible, to
the initramfs. (The potential exists, therefore it must be addressed for
a solution even to be considered as robust.)

 Do you now need another script to run after every emerge to check that
files in your initramfs are in sync? After all, we've been told the
initramfs is "the new root": iow that we should think of it as our rescue
system, so this matters.

 At the same time, we've been told "it's only a few hundred kilobytes at
most." That contradiction has never been answered, either.

[1] http://lwn.net/Articles/492134/
[2] http://forums.gentoo.org/viewtopic-t-901206.html
[3] http://forums.gentoo.org/viewtopic-t-934678.html
[4] http://forums.gentoo.org/viewtopic-p-6987380.html#6987380
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)