On Fri, 16 Dec 2011 14:52:36 +0100, Josselin Mouette <joss@debian.org> wrote: > Le jeudi 08 décembre 2011 à 20:16 +0100, Marco d'Itri a écrit : > > Let's try to summarize the possible configurations and what is needed to > > support them: > > > > - / and /usr are in the same filesystem > > * no changes are needed > > - / and /usr are in different filesystems > > - an initramfs is or can be used and will mount /usr > > * initramfs-tools will be updated, no operational changes are needed > > - the platform does not support an initramfs > > * I am still waiting for somebody to enumerate them, but I believe > > that I can design a suitable workaround > > - the administrator refuses to use an initramfs > > * tough luck for them > > After a big week of discussions, I don’t think there have been any valid > objections against the scheme you are proposing. It still allows to > split / and /usr for various reasons (the most useful one today being > encrypting / and not /usr). Once this is done I don’t think there are > valid reasons to not move back stuff from / to /usr, either. > > The cost is not too high, the number of systems it breaks is extremely > small, and the long-term gain is significant. I've read all of these threads, but I'm afraid I'm still a little befuddled about the pros and cons. Pro seems to be saving some effort for packagers when RedHat as upstream, say, makes changes that assume /usr is always available, that's clear. It also seems that Gnome folks[1] will be able to relax and stop worrying about whether their stuff should really be on / and/or whether /usr will be available early in the boot -- which sounds great for them, but I'm left wondering if allowing people to be less rigorous in this area is good for the embedded folks, for example, because it gives developers an excuse to say they don't care about how much they've entangled the early boot with things that are only important if you're running a full desktop environment. I'm also wondering: Does this mean that this change compromises our ability to recover from a failure that renders a system unable to mount /usr for some reason? Cheers, Phil. [1] or at least those who package things upon which Gnome depends, and which need to be around early in the boot -- and I'd imagine that KDE is similar in many respects, so I'm not being specifically anti-gnome. I just don't happen to know enough about Gnome/KDE or any other such desktoppy stuff to discover the fine details here. It would be really helpful if someone would spell out the packages that have had to be twisted into a funny shape to fit into the current scheme, so that the long-term gains we are expecting were then revealed. -- |)| Philip Hands [+44 (0)20 8530 9560] http://www.hands.com/ |-| HANDS.COM Ltd. http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND
Attachment:
pgpGIbebStxlM.pgp
Description: PGP signature