from / to /usr/: a summary

classic Classic list List threaded Threaded
162 messages Options
1234 ... 9
Reply | Threaded
Open this post in threaded view
|

from / to /usr/: a summary

Marco d'Itri
On Dec 07, Stephan Seitz <[hidden email]> wrote:

> If this is the future way and the way the developer want to go, then
> the way will succeed in time, but as Goswin said, it will take time.
>
> The admins who think the new way is bad will not change their
> systems.  New admins may think otherwise, and if the old server will
> be replaced, they change the system to the new way.
I do not think you understand well the issue: we cannot accomodate
everybody, this is not just a matter of local policy.
Two issues are being discussed here:
- mounting /usr in the initramfs
- symlinking /bin, /sbin and /lib to their /usr counterparts[1]

The first feature sooner or later will be needed to support some major
software: this is not just about udev, it going to be required soon by
major desktop/gnome components.
The second point, which depends on the first one, does not need to be
implemented and if implemented could conceivably be optional.

Some changes are coming from upstream and we will have to either embrace
them or actively revert them.
Both options require work on our part, and it would be sensible to
understand how much work will be needed in each situation.


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

Some people also argued that they would be more comfortable with a
smaller root file system which can act as a rescue system, but I am
not sure about which tools they would miss from an initramfs with
busybox and fsck.
A side note, I think it would be interesting to design a small
initramfs in the 25-50 MB range which could permanently live in /boot
and work as a complete rescue system like the tiny live CDs do.


[1] https://fedoraproject.org/wiki/Features/UsrMove

--
ciao,
Marco

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: from / to /usr/: a summary

Jonathan Nieder
Hi,

Just a quick side-note.

Marco d'Itri wrote:

> Some changes are coming from upstream and we will have to either embrace
> them or actively revert them.

There is a third option: help upstream to maintain what they consider
the "legacy" alternative.  Many upstreams, including at Red Hat, seem
to be willing to work with downstream packagers that contribute
patches.

Of course that has nothing to do with the real motivation no one has
mentioned, which is that deciding for each binary whether to put it in
/bin or /usr/bin is a pain in the neck.  It very well may be sensible
to tweak the boot process to mount /usr sooner to avoid that trouble.
The main technical difficulty seems to be platforms where it is common
to boot without an initramfs (for example, if it is hard to
reconfigure the bootloader and the bootloader is already set up to use
a plain kernel).

Hope that helps,
Jonathan


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20111208194638.GA5255@...

Reply | Threaded
Open this post in threaded view
|

Re: from / to /usr/: a summary

wookey-4
In reply to this post by Marco d'Itri
+++ Marco d'Itri [2011-12-08 20:16 +0100]:
> On Dec 07, Stephan Seitz <[hidden email]> wrote:
>
>   - 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

Anything that needs to boot fast (which is a lot of consumer-oriented
equipment like TVs, phones, pdas, VOIP kit etc). One good way to do
this is not waste time with an intramfs that will soon be superceded
with a pivot-root.

However in practice it is very hard to support this sort of thing in
Debian anyway, because the way you get fast booting is by removing all
the generality in scripts which check what sort of hardware and then
load appropriate modules, drivers, programs and firmwares, and
pre-configuring as much as possible. This approach directly
contradicts the 'universal OS' approach of making things as generic as
possible, and the requirments of a binary distro which has to build
binaries to support 'everything'.

So there probably aren't too many people who both _really really_
don't want/can't have an initramfs and _also_ install Debian.

Most arm bootloaders _can_ load an initramfs, or at least can load a
combined kernel+initramfs image (I'm not sure that debian tools can
_make_ a combined kernel+initrd image - I've always used another tool
like buildroot to do that?), so the number of platforms that can;t
support this at all is very small.

There are quite good reasons why you wouldn't want to do thing that
way though. We should at least do our best not to make things
unreasonably difficult for people in this situation, even if we chose
not to really 'support' it.



Wookey
--
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20111208194641.GK28838@...

Reply | Threaded
Open this post in threaded view
|

Re: from / to /usr/: a summary

Ben Hutchings-3
On Thu, Dec 08, 2011 at 07:46:41PM +0000, Wookey wrote:

> +++ Marco d'Itri [2011-12-08 20:16 +0100]:
> > On Dec 07, Stephan Seitz <[hidden email]> wrote:
> >
> >   - 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
>
> Anything that needs to boot fast (which is a lot of consumer-oriented
> equipment like TVs, phones, pdas, VOIP kit etc). One good way to do
> this is not waste time with an intramfs that will soon be superceded
> with a pivot-root.
>
> However in practice it is very hard to support this sort of thing in
> Debian anyway, because the way you get fast booting is by removing all
> the generality in scripts which check what sort of hardware and then
> load appropriate modules, drivers, programs and firmwares, and
> pre-configuring as much as possible. This approach directly
> contradicts the 'universal OS' approach of making things as generic as
> possible, and the requirments of a binary distro which has to build
> binaries to support 'everything'.

Indeed.

> So there probably aren't too many people who both _really really_
> don't want/can't have an initramfs and _also_ install Debian.

Currently the only Debian architectures which doesn't use
initramfs by default are the MIPS architectures.  And I understand
that most of the boot loaders for MIPS can actually support an
initramfs.

> Most arm bootloaders _can_ load an initramfs, or at least can load a
> combined kernel+initramfs image (I'm not sure that debian tools can
> _make_ a combined kernel+initrd image - I've always used another tool
> like buildroot to do that?), so the number of platforms that can;t
> support this at all is very small.
 
We have a policy for kernel and initramfs hooks
<http://kernel-handbook.alioth.debian.org/ch-update-hooks.html>
that should allow that sort of thing to be done without the need
for specific support by the kernel or initramfs packags.

Ben.

> There are quite good reasons why you wouldn't want to do thing that
> way though. We should at least do our best not to make things
> unreasonably difficult for people in this situation, even if we chose
> not to really 'support' it.

--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
                                                              - Albert Camus


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20111208201227.GN3366@...

Reply | Threaded
Open this post in threaded view
|

Re: from / to /usr/: a summary

Iustin Pop-3
In reply to this post by Marco d'Itri
On Thu, Dec 08, 2011 at 08:16:57PM +0100, Marco d'Itri wrote:

> On Dec 07, Stephan Seitz <[hidden email]> wrote:
>
> > If this is the future way and the way the developer want to go, then
> > the way will succeed in time, but as Goswin said, it will take time.
> >
> > The admins who think the new way is bad will not change their
> > systems.  New admins may think otherwise, and if the old server will
> > be replaced, they change the system to the new way.
> I do not think you understand well the issue: we cannot accomodate
> everybody, this is not just a matter of local policy.
> Two issues are being discussed here:
> - mounting /usr in the initramfs
> - symlinking /bin, /sbin and /lib to their /usr counterparts[1]
>
> The first feature sooner or later will be needed to support some major
> software: this is not just about udev, it going to be required soon by
> major desktop/gnome components.
Please excuse me if I misunderstand things, but there was no information
about this in the previous thread: why would gnome _ever_ care when /usr
is mounted?

This seems like a violation of proper layering, if the desktop software
care about such minute details of the boot sequence.

Am I just misunderstanding things? (I hope so!)

iustin

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: from / to /usr/: a summary

Simon McVittie-7
On Thu, 08 Dec 2011 at 21:14:05 +0100, Iustin Pop wrote:
> Please excuse me if I misunderstand things, but there was no information
> about this in the previous thread: why would gnome _ever_ care when /usr
> is mounted?

For "GNOME" read "system services which GNOME depends on", presumably.

    S


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20111208203403.GA16793@...

Reply | Threaded
Open this post in threaded view
|

Re: from / to /usr/: a summary

Marco d'Itri
In reply to this post by Jonathan Nieder
On Dec 08, Jonathan Nieder <[hidden email]> wrote:

> There is a third option: help upstream to maintain what they consider
> the "legacy" alternative.  Many upstreams, including at Red Hat, seem
> to be willing to work with downstream packagers that contribute
> patches.
In this case, it has been made repeatedly clear by the upstream
maintainers that they have no desire to accept code to support this and
other things.
(Often, the same code was actually removed from the package.)

--
ciao,
Marco

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: from / to /usr/: a summary

Marco d'Itri
In reply to this post by wookey-4
On Dec 08, Wookey <[hidden email]> wrote:

> However in practice it is very hard to support this sort of thing in
> Debian anyway, because the way you get fast booting is by removing all
> the generality in scripts which check what sort of hardware and then
Agreed. Also, emebedded devices will probably either have / and /usr on
the same file system or even benefit from the everything-in-/usr
approach.

> There are quite good reasons why you wouldn't want to do thing that
> way though. We should at least do our best not to make things
> unreasonably difficult for people in this situation, even if we chose
> not to really 'support' it.
We need to understand if these people object to using an initramfs in
principle or just to the ones generated by initramfs-tools.

On Dec 08, Ben Hutchings <[hidden email]> wrote:

> Currently the only Debian architectures which doesn't use
> initramfs by default are the MIPS architectures.  And I understand
> that most of the boot loaders for MIPS can actually support an
> initramfs.
Do you know the reason for not using initramfs by default?
Is it still relevant nowadays?
Are there any MIPS porters around who can provide their opinions on the
issue?

--
ciao,
Marco

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: from / to /usr/: a summary

Timo Lindfors-2
In reply to this post by wookey-4
Wookey <[hidden email]> writes:
> this is not waste time with an intramfs that will soon be superceded
> with a pivot-root.

Not really related to the main issue but do note that pivot_root syscall
has not been used for quite some time. run-init basically just uses
unlink, mount, chroot and execve.

> Most arm bootloaders _can_ load an initramfs, or at least can load a

All of the two arm boot loaders that are in debian at least can :-)


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/84r50e8q5q.fsf@...

Reply | Threaded
Open this post in threaded view
|

Re: from / to /usr/: a summary

Jonathan Nieder
In reply to this post by Marco d'Itri
Marco d'Itri wrote:

> In this case, it has been made repeatedly clear by the upstream
> maintainers that they have no desire to accept code to support this and
> other things.

_If_ upstream is taking the stance that portability to other platforms
is something they want nothing to do with, then that's fine.  Each
developer is free to work on what she finds useful.  It just means
that one has to find some other way to cooperate with others
interested in portability patches.

I don't think this phenomenon is in any way unique to udev.  E.g., if
I remember correctly then core (OpenBSD) OpenSSH development and
portable OpenSSH are maintained as distinct projects.

> (Often, the same code was actually removed from the package.)

BTW, thanks for your work, and I don't mean to imply that the choices
you are advocating are bad ones.  Just that I'd find proposals
justified on technical grounds more convincing than acting helpless
and claiming we are at the mercy of an upstream that is not willing to
listen.

Sincerely,
Jonathan


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20111209062504.GA9082@...

Reply | Threaded
Open this post in threaded view
|

Re: from / to /usr/: a summary

Goswin von Brederlow-2
In reply to this post by Marco d'Itri
[hidden email] (Marco d'Itri) writes:

> Some people also argued that they would be more comfortable with a
> smaller root file system which can act as a rescue system, but I am
> not sure about which tools they would miss from an initramfs with
> busybox and fsck.

lvm, dmsetup, mdadm, crypto stuff for obvious things you just forgot to
mention. Usualy initramfs would included them as needed. But I had
enough cases where I moved my / or /usr around to a different
configuration and the initramfs stoped working (largely because you
forget to rebuild it).

For a more extensive repair session you also wan't bash, openvt, ssh,
netcat, dd_rescue, tar, gzip, less, $EDITOR, ifconfig, ip, ping, rsync,
... The list goes on and on I'm sure. I think for most people the time
is past where we need / as rescue system can't have a real live/rescue
image in /boot instead. And the rest probably boots one over the
network.

> A side note, I think it would be interesting to design a small
> initramfs in the 25-50 MB range which could permanently live in /boot
> and work as a complete rescue system like the tiny live CDs do.

As I mentioned I have a bug open (in the grml bug tracker) about
providing a grml.deb. That would install an image in /boot and add
itself to the bootloader. The small grml image is more like 180MB than
25-50MB but it is a verry good rescue system. And harddisk space is
usualy cheap.

But if someone feels the need for something more compact then a 25-50 MB
image could be made for sure. I've been doing this for years now in
various forms:

- have a 2nd Debian with just base installed on the disk as alternat
  boot entry
- build an initrd with rescue tools
- build an initramfs with rescue toosl
- have Debian Installer over netboot available
- add a Debian Installer image to /boot
- add grml to /boot

Actualy how about having Debian-Installer build a deb package that
installs an image in /boot and adds it to the bootloader? A businesscard
image would be just about the size you requested.

+1000 on the idea of providing some sort of rescue image in /boot via a
deb in Debian.

MfG
        Goswin


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/871use43d1.fsf@...

Reply | Threaded
Open this post in threaded view
|

Re: from / to /usr/: a summary

Goswin von Brederlow-2
In reply to this post by Jonathan Nieder
Jonathan Nieder <[hidden email]> writes:

> Hi,
>
> Just a quick side-note.
>...
> The main technical difficulty seems to be platforms where it is common
> to boot without an initramfs (for example, if it is hard to
> reconfigure the bootloader and the bootloader is already set up to use
> a plain kernel).
>
> Hope that helps,
> Jonathan

Does it have to be an initramfs? What if you unpack the generated
initramfs to /initramfs and divert /sbin/init to run from there.

Sure it would require some tricks and some binaries in /. You could do
it with just a working shell in /. Nowhere the amount of tools needed to
mount /usr.

It wouldn't be the most pretty but that would be the cost for setups
that can't have initramfs.

MfG
        Goswin


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/87wra62ogh.fsf@...

Reply | Threaded
Open this post in threaded view
|

Re: from / to /usr/: a summary

Stephan Seitz-5
In reply to this post by Simon McVittie-7
On Thu, Dec 08, 2011 at 08:34:03PM +0000, Simon McVittie wrote:
>On Thu, 08 Dec 2011 at 21:14:05 +0100, Iustin Pop wrote:
>> Please excuse me if I misunderstand things, but there was no information
>> about this in the previous thread: why would gnome _ever_ care when /usr
>> is mounted?
>For "GNOME" read "system services which GNOME depends on", presumably.

Such services should not be started in the early boot stage. And when the
system switches to runlevel 2, /usr is mounted.

So, this is no excuse.

Shade and sweet water!

        Stephan

--
| Stephan Seitz             E-Mail: [hidden email] |
| PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html |

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: from / to /usr/: a summary

Stephan Seitz-5
In reply to this post by Goswin von Brederlow-2
On Fri, Dec 09, 2011 at 08:21:30AM +0100, Goswin von Brederlow wrote:
>As I mentioned I have a bug open (in the grml bug tracker) about
>providing a grml.deb. That would install an image in /boot and add
>itself to the bootloader. The small grml image is more like 180MB than
>25-50MB but it is a verry good rescue system. And harddisk space is
>usualy cheap.

Maybe, but none of my systems have such a big /boot partition. Older
systems have about 50MB, newer systems about 150MB. More is not needed.
And do you know why this will not change in the next time? Because I can
upgrade Debian from one release to another without reinstalling
everything. This is one of the main reasons why I use Debian.

If you wish to through this great advantage away because of crappy
software, fine. But be prepared that you will lose people.

Shade and sweet water!

        Stephan

--
| Stephan Seitz             E-Mail: [hidden email] |
| PGP Public Keys: http://fsing.rootsland.net/~stse/pgp.html |

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: from / to /usr/: a summary

Marco d'Itri
In reply to this post by Stephan Seitz-5
On Dec 09, Stephan Seitz <[hidden email]> wrote:

> >For "GNOME" read "system services which GNOME depends on", presumably.
> Such services should not be started in the early boot stage. And
> when the system switches to runlevel 2, /usr is mounted.
>
> So, this is no excuse.
Great, now that you had the right idea everything will just work.

--
ciao,
Marco

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: from / to /usr/: a summary

Tollef Fog Heen
In reply to this post by Stephan Seitz-5
]] Stephan Seitz

> On Thu, Dec 08, 2011 at 08:34:03PM +0000, Simon McVittie wrote:
> >On Thu, 08 Dec 2011 at 21:14:05 +0100, Iustin Pop wrote:
> >> Please excuse me if I misunderstand things, but there was no information
> >> about this in the previous thread: why would gnome _ever_ care when /usr
> >> is mounted?
> >For "GNOME" read "system services which GNOME depends on", presumably.
>
> Such services should not be started in the early boot stage. And when
> the system switches to runlevel 2, /usr is mounted.

While we do have too much starting in before basic.target/in rcS, some
bits like udev have to start before (and is used by parts of GNOME).

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/87pqfxaajy.fsf@...

Reply | Threaded
Open this post in threaded view
|

Re: from / to /usr/: a summary

Henrique de Moraes Holschuh
In reply to this post by Marco d'Itri
On Thu, 08 Dec 2011, Marco d'Itri wrote:
> > There are quite good reasons why you wouldn't want to do thing that
> > way though. We should at least do our best not to make things
> > unreasonably difficult for people in this situation, even if we chose
> > not to really 'support' it.
> We need to understand if these people object to using an initramfs in
> principle or just to the ones generated by initramfs-tools.

The real nastyness of initramfs-like stuff is that it _will_ cause grief
if you fail to update it when you edit /etc/fstab, mdadm / lvm /
device-mapper config, etc in some configs.  It is also slower.

initramfs-tools is rather good at what it does, I doubt it is the
problem.  That doesn't mean there is not anything to improve in our
helpers (and therefore in the initramfs itself), and initramfs-tools
could use better documentation last time I checked (a few months ago).

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/20111209220633.GA25352@...

Reply | Threaded
Open this post in threaded view
|

Re: from / to /usr/: a summary

Goswin von Brederlow-2
In reply to this post by Stephan Seitz-5
Stephan Seitz <[hidden email]> writes:

> On Fri, Dec 09, 2011 at 08:21:30AM +0100, Goswin von Brederlow wrote:
>>As I mentioned I have a bug open (in the grml bug tracker) about
>>providing a grml.deb. That would install an image in /boot and add
>>itself to the bootloader. The small grml image is more like 180MB than
>>25-50MB but it is a verry good rescue system. And harddisk space is
>>usualy cheap.
>
> Maybe, but none of my systems have such a big /boot partition. Older
> systems have about 50MB, newer systems about 150MB. More is not needed.
> And do you know why this will not change in the next time? Because I
> can upgrade Debian from one release to another without reinstalling
> everything. This is one of the main reasons why I use Debian.
>
> If you wish to through this great advantage away because of crappy
> software, fine. But be prepared that you will lose people.
>
> Shade and sweet water!
>
> Stephan

Grub2 can load the image from /usr/share/rescue-image/rescue.img if you
don't have that encrypted. Space in /boot is indeed precious if you made
that a seperate partitions years ago. Just for comparison:

Kernel without module and a kernel independent initramfs with some
rescue tools included:
-rw-r--r--  1 root root 4.5M May 14  2011 vmlinuz-2.6.39-rc7-xen-1
-rw-r--r--  1 root root 3.0M Feb 21  2010 initramfs.2010.02.18

With my own kernel I use up 4.5MB per kernel version I keep around plus
one initramfs for all versions. Or 9-10 kernels for your 50MB /boot.


Debian kernel and initramfs:
-rw-r--r--  1 root root 2.6M Nov 14 09:21 vmlinuz-3.1.0-1-amd64
-rw-r--r--  1 root root  11M Nov 29 18:01 initrd.img-3.1.0-1-amd64

With Debians kernel it's down to 4 and no rescue tools included.

MfG
        Goswin


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/87k4652vph.fsf@...

Reply | Threaded
Open this post in threaded view
|

Re: from / to /usr/: a summary

Josselin Mouette
In reply to this post by Marco d'Itri
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.

--
 .''`.      Josselin Mouette
: :' :
`. `'
  `-


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/1324043556.3443.686.camel@pi0307572

Reply | Threaded
Open this post in threaded view
|

Re: from / to /usr/: a summary

Philip Hands
On Fri, 16 Dec 2011 14:52:36 +0100, Josselin Mouette <[hidden email]> 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

attachment0 (851 bytes) Download Attachment
1234 ... 9