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

[Alec Warner]

On Mon, Nov 19, 2012 at 5:07 AM, Steven J. Long
<slong@××××××××××××××××××.uk> wrote:
> 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.

Debian / Ubuntu have a tool that basically does this. Its
update-initramfs. I believe it is called from..the postinst of
packages that are supposed to be in the initramfs? honestly I'd have
to look up how they implemented it.

-A

>
>  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 ;-)
>