[gentoo-user] systemd installation location

[gentoo-user] systemd installation location

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 871 bytes --]

All,

I can clarify one part of the systemd issue, because I have been
involved in this part of the issue for months. Again,  I am not trying
to start a dispute here, just providing a clarification.

The choice to install all of the systemd binaries in /usr is not an
upstream choice. It was a choice made a year ago when our systemd team
was one person [1], and now the team doesn't want to change it because
it would require users to go through a migration, and the rest of the
team doesn't see a benefit in changing it since it still links to
libraries in /usr/lib.

I joined the team, primarily to take responsibility for this change and
to try to make it go as smoothly as possible, but I was overruled even
though upstream gave us a pretty strong warning about it.

William

[1]
http://blogs.gentoo.org/mgorny/2012/01/04/moving-systemd-into-usr-the-technical-side/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] systemd installation location

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/29/2013 02:52 PM, William Hubbs wrote:
> All,
> 
> I can clarify one part of the systemd issue, because I have been 
> involved in this part of the issue for months. Again,  I am not
> trying to start a dispute here, just providing a clarification.
> 
> The choice to install all of the systemd binaries in /usr is not
> an upstream choice. It was a choice made a year ago when our
> systemd team was one person [1], and now the team doesn't want to
> change it because it would require users to go through a migration,
> and the rest of the team doesn't see a benefit in changing it since
> it still links to libraries in /usr/lib.
> 
> I joined the team, primarily to take responsibility for this change
> and to try to make it go as smoothly as possible, but I was
> overruled even though upstream gave us a pretty strong warning
> about it.
> 
> William
> 
> [1] 
> http://blogs.gentoo.org/mgorny/2012/01/04/moving-systemd-into-usr-the-technical-side/
>
> 
Ouch. So systemd upstream doesn't suggest putting binaries in /usr?
That shows at least a little respect for /bin, et al. Based on the
blog post, I'm getting the feeling that -- for systemd anyway -- the
issues with /usr are caused by its dependencies rather than systemd
itself. If dbus and whatnot were in /bin where they belong, the need
for an initramfs (for separate /usr) and/or dealing with things in a
non-standard place wouldn't need to happen.

I'm not affected by anything regarding the /usr switch, but I'd like
to have a good talk with the first person who decided a
system-critical binary belonged in /usr instead of /bin or /sbin.
They've created a mess for every distro and any project that depends
on their work.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSSMu5AAoJEJUrb08JgYgHFz4H/iyZt6MlTeW702KOlIy2Ydse
mzsfiyPfPz8Rbz0Mqp5/17R8aQzOUG4l6dZS7d9HFKuMCG7t+kNZCSvxD69XeTVO
tZY6YjHCGQaE6WaAMbiasXfRTeRt4ZDtP5l/lCUsYcTCWN13PyIcHCb5rGNHnHqq
J/OcSeF5EoS+G/uSAuzDVaQ5wa0Z0qkqVSqQGjJ5NUHYIA5ZrtYpMNDR+MkFYYAB
7I4JE5kDXRYoBSiLLDb7tI7F1nGogHXxzECmMYW4ZneU0AJwhUAK0kU+oTHY2Z9Q
8TcjpdaG1BH4gA2NT+i+ZJz4XNqkMPa2vbvhcfGFs9Dg7IwabiuunOzh0GQM1S4=
=jgci
-----END PGP SIGNATURE-----

Re: [gentoo-user] systemd installation location

[Mark David Dumlao]

On Mon, Sep 30, 2013 at 8:54 AM, Daniel Campbell <lists@sporkbox.us> wrote:
> I'm not affected by anything regarding the /usr switch, but I'd like
> to have a good talk with the first person who decided a
> system-critical binary belonged in /usr instead of /bin or /sbin.
> They've created a mess for every distro and any project that depends
> on their work.

As I've pointed out before:
- "system-critical" is actually dependent on the system. A system dependent
   on an smb share will find smbmount system critical. One dependent on
   zfs-fuse will find fuse system critical. With the advent of fuse, arbitrary



> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.20 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJSSMu5AAoJEJUrb08JgYgHFz4H/iyZt6MlTeW702KOlIy2Ydse
> mzsfiyPfPz8Rbz0Mqp5/17R8aQzOUG4l6dZS7d9HFKuMCG7t+kNZCSvxD69XeTVO
> tZY6YjHCGQaE6WaAMbiasXfRTeRt4ZDtP5l/lCUsYcTCWN13PyIcHCb5rGNHnHqq
> J/OcSeF5EoS+G/uSAuzDVaQ5wa0Z0qkqVSqQGjJ5NUHYIA5ZrtYpMNDR+MkFYYAB
> 7I4JE5kDXRYoBSiLLDb7tI7F1nGogHXxzECmMYW4ZneU0AJwhUAK0kU+oTHY2Z9Q
> 8TcjpdaG1BH4gA2NT+i+ZJz4XNqkMPa2vbvhcfGFs9Dg7IwabiuunOzh0GQM1S4=
> =jgci
> -----END PGP SIGNATURE-----
>



-- 
This email is:    [ ] actionable   [ ] fyi        [ ] social
Response needed:  [ ] yes          [ ] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [ ] none

Re: [gentoo-user] systemd installation location

[Daniel Campbell]

On 09/29/2013 08:17 PM, Mark David Dumlao wrote:
> On Mon, Sep 30, 2013 at 8:54 AM, Daniel Campbell <lists@sporkbox.us> wrote:
>> I'm not affected by anything regarding the /usr switch, but I'd like
>> to have a good talk with the first person who decided a
>> system-critical binary belonged in /usr instead of /bin or /sbin.
>> They've created a mess for every distro and any project that depends
>> on their work.
> 
> As I've pointed out before:
> - "system-critical" is actually dependent on the system. A system dependent
>    on an smb share will find smbmount system critical. One dependent on
>    zfs-fuse will find fuse system critical. With the advent of fuse, arbitrary
> 
> 
> 
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.20 (GNU/Linux)
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQEcBAEBAgAGBQJSSMu5AAoJEJUrb08JgYgHFz4H/iyZt6MlTeW702KOlIy2Ydse
>> mzsfiyPfPz8Rbz0Mqp5/17R8aQzOUG4l6dZS7d9HFKuMCG7t+kNZCSvxD69XeTVO
>> tZY6YjHCGQaE6WaAMbiasXfRTeRt4ZDtP5l/lCUsYcTCWN13PyIcHCb5rGNHnHqq
>> J/OcSeF5EoS+G/uSAuzDVaQ5wa0Z0qkqVSqQGjJ5NUHYIA5ZrtYpMNDR+MkFYYAB
>> 7I4JE5kDXRYoBSiLLDb7tI7F1nGogHXxzECmMYW4ZneU0AJwhUAK0kU+oTHY2Z9Q
>> 8TcjpdaG1BH4gA2NT+i+ZJz4XNqkMPa2vbvhcfGFs9Dg7IwabiuunOzh0GQM1S4=
>> =jgci
>> -----END PGP SIGNATURE-----
>>
> 
> 
> 
It's fairly obvious (to me, anyway) that anything mounting a filesystem
and making it available is system-critical. I run samba and don't need
it for boot, but like you said, someone may need that. I wouldn't see a
problem with smbmount being in /bin. FUSE deserves similar treatment.
LVM's another that probably deserves special treatment.

Re: [gentoo-user] systemd installation location

[Mark David Dumlao]

On Mon, Sep 30, 2013 at 9:22 AM, Daniel Campbell <lists@sporkbox.us> wrote:
> It's fairly obvious (to me, anyway) that anything mounting a filesystem
> and making it available is system-critical. I run samba and don't need
> it for boot, but like you said, someone may need that. I wouldn't see a
> problem with smbmount being in /bin. FUSE deserves similar treatment.
> LVM's another that probably deserves special treatment.
>

If you allow FUSE you've already failed, because arbitrary programs can
be required by FUSE filesystems. Suddenly your ssh client should be pushed
to /, or your telnet, or rsync, or ftp.
-- 
This email is:    [ ] actionable   [x] fyi        [ ] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] systemd installation location

[Daniel Campbell]

On 09/29/2013 08:51 PM, Mark David Dumlao wrote:
> On Mon, Sep 30, 2013 at 9:22 AM, Daniel Campbell <lists@sporkbox.us> wrote:
>> It's fairly obvious (to me, anyway) that anything mounting a filesystem
>> and making it available is system-critical. I run samba and don't need
>> it for boot, but like you said, someone may need that. I wouldn't see a
>> problem with smbmount being in /bin. FUSE deserves similar treatment.
>> LVM's another that probably deserves special treatment.
>>
> 
> If you allow FUSE you've already failed, because arbitrary programs can
> be required by FUSE filesystems. Suddenly your ssh client should be pushed
> to /, or your telnet, or rsync, or ftp.
> 
FUSE is that lenient with what it can use to mount with? o_O

Re: [gentoo-user] systemd installation location

[Mark David Dumlao]

On Mon, Sep 30, 2013 at 10:01 AM, Daniel Campbell <lists@sporkbox.us> wrote:
> On 09/29/2013 08:51 PM, Mark David Dumlao wrote:
>> On Mon, Sep 30, 2013 at 9:22 AM, Daniel Campbell <lists@sporkbox.us> wrote:
>>> It's fairly obvious (to me, anyway) that anything mounting a filesystem
>>> and making it available is system-critical. I run samba and don't need
>>> it for boot, but like you said, someone may need that. I wouldn't see a
>>> problem with smbmount being in /bin. FUSE deserves similar treatment.
>>> LVM's another that probably deserves special treatment.
>>>
>>
>> If you allow FUSE you've already failed, because arbitrary programs can
>> be required by FUSE filesystems. Suddenly your ssh client should be pushed
>> to /, or your telnet, or rsync, or ftp.
>>
> FUSE is that lenient with what it can use to mount with? o_O

Fuse is filesystems in userspace. The hard problem that isn't obvious
here, is that
anybody can come up with a userspace filesystem, and there is ZERO intelligence
in the package manager that some filesystem is dependent on some userspace
logic.

for example, there's a filesystem called sshfs. It allows you to view an ssh
connection as a directory. sshfs itself could be in /, but it depends
on ssh and its
libraries, which are normally in /usr. Now what do you do? Just to
support sshfs,
you have to move or copy all those programs to /. Portage doesn't know this.
Ebuilds don't know this. Manual compiles don't know this. What should the ssh
packagers do? What should the fuse-sshfs packagers do? What should users
who are manually rolling out sshfs do?

How about when you develop the next revolutionary crazy filesystem that
allows you to view emacs sessions as directories? What should the emacs
packagers do? What should the fuse-emacsfs packagers do? What should users
manually rolling out that do?

You want to automatically version /etc using some filesystem that uses a git
backend (I'll call it gitfs). What should git packagers do? What
should fuse-gitfs
packagers do? etc.... How about svnfs? hgfs? bzrfs? scpfs? ...
-- 
This email is:    [ ] actionable   [x] fyi        [ ] social
Response needed:  [ ] yes          [ ] up to you  [x] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] systemd installation location

[Daniel Campbell]

On 09/29/2013 09:25 PM, Mark David Dumlao wrote:
> On Mon, Sep 30, 2013 at 10:01 AM, Daniel Campbell <lists@sporkbox.us> wrote:
>> On 09/29/2013 08:51 PM, Mark David Dumlao wrote:
>>> On Mon, Sep 30, 2013 at 9:22 AM, Daniel Campbell <lists@sporkbox.us> wrote:
>>>> It's fairly obvious (to me, anyway) that anything mounting a filesystem
>>>> and making it available is system-critical. I run samba and don't need
>>>> it for boot, but like you said, someone may need that. I wouldn't see a
>>>> problem with smbmount being in /bin. FUSE deserves similar treatment.
>>>> LVM's another that probably deserves special treatment.
>>>>
>>>
>>> If you allow FUSE you've already failed, because arbitrary programs can
>>> be required by FUSE filesystems. Suddenly your ssh client should be pushed
>>> to /, or your telnet, or rsync, or ftp.
>>>
>> FUSE is that lenient with what it can use to mount with? o_O
> 
> Fuse is filesystems in userspace. The hard problem that isn't obvious
> here, is that
> anybody can come up with a userspace filesystem, and there is ZERO intelligence
> in the package manager that some filesystem is dependent on some userspace
> logic.
> 
> for example, there's a filesystem called sshfs. It allows you to view an ssh
> connection as a directory. sshfs itself could be in /, but it depends
> on ssh and its
> libraries, which are normally in /usr. Now what do you do? Just to
> support sshfs,
> you have to move or copy all those programs to /. Portage doesn't know this.
> Ebuilds don't know this. Manual compiles don't know this. What should the ssh
> packagers do? What should the fuse-sshfs packagers do? What should users
> who are manually rolling out sshfs do?
> 
> How about when you develop the next revolutionary crazy filesystem that
> allows you to view emacs sessions as directories? What should the emacs
> packagers do? What should the fuse-emacsfs packagers do? What should users
> manually rolling out that do?
> 
> You want to automatically version /etc using some filesystem that uses a git
> backend (I'll call it gitfs). What should git packagers do? What
> should fuse-gitfs
> packagers do? etc.... How about svnfs? hgfs? bzrfs? scpfs? ...
> 
Ah, I wasn't aware of how flexible and arbitrary fuse could be. In that
case I'd probably keep it out of /bin for the reasons you outlined. But
that doesn't solve the problem of "what if people want to boot with
fuse?". At least, not without an initramfs. And then we've created a
similar problem.

If the proposed solution is all binaries and libraries in the same
root/prefix directory, then why call it /usr? It has little to do with
users if it's nothing but binaries, libraries, etc. In addition, would a
local directory still be under this, for user-compiled programs not
maintained by the PM? Or does that deserve a different top level directory?

Then there's /opt, whose purpose I'm still not sure of. This is
strengthening the idea that something new should be thought up and
drafted. Not necessarily by us at Gentoo, but *somebody*. If I was crazy
and knowledgeable enough I'd volunteer myself.

Re: [gentoo-user] systemd installation location

[Pandu Poluan]

[-- Attachment #1: Type: text/plain, Size: 1577 bytes --]

On Sep 30, 2013 9:31 AM, "Daniel Campbell" <lists@sporkbox.us> wrote:
>

--- le snip ---

> If the proposed solution is all binaries and libraries in the same
> root/prefix directory, then why call it /usr?

My question exactly.

Why install to /usr at all, leaving /bin and /sbin a practically empty
directory containing symlinks only?

I mean, I have no quarrel with / and /usr separation, having had them in
the same partition for ages... but why not do it the other way around,
i.e., put everything in / and have /usr be a container for symlinks?

> It has little to do with
> users if it's nothing but binaries, libraries, etc. In addition, would a
> local directory still be under this, for user-compiled programs not
> maintained by the PM? Or does that deserve a different top level
directory?
>
> Then there's /opt, whose purpose I'm still not sure of. This is
> strengthening the idea that something new should be thought up and
> drafted.

IIRC, it was supposed to contain third-party binaries, i.e., things not
available in a distro's package repo. Thus, when one's tired of a
third-party binary package, he/she can just delete the relevant directory
under /opt, because the third-party package might not be uninstallable
using the distro's package management system (if any).

Of course, he/she might have to clean up the leftover crud in /etc, but
those are usually small and can safely be ignored. Except perhaps startup
initscripts.

> Not necessarily by us at Gentoo, but *somebody*. If I was crazy
> and knowledgeable enough I'd volunteer myself.
>

Rgds,
--

[-- Attachment #2: Type: text/html, Size: 1966 bytes --]

Re: [gentoo-user] systemd installation location

[Mark David Dumlao]

On Mon, Sep 30, 2013 at 12:13 PM, Pandu Poluan <pandu@poluan.info> wrote:
>
> On Sep 30, 2013 9:31 AM, "Daniel Campbell" <lists@sporkbox.us> wrote:
>>
>
> --- le snip ---
>
>> If the proposed solution is all binaries and libraries in the same
>> root/prefix directory, then why call it /usr?
>
> My question exactly.
>
> Why install to /usr at all, leaving /bin and /sbin a practically empty
> directory containing symlinks only?
>
> I mean, I have no quarrel with / and /usr separation, having had them in the
> same partition for ages... but why not do it the other way around, i.e., put
> everything in / and have /usr be a container for symlinks?
>

If the binaries and libraries are kept together, /usr can actually be made
reliably sharable, independent of local settings in /etc. It can also be made
properly readonly, or otherwise use different mount options than /.

Most of the things in /usr have the same read-write characteristics.
They're mostly chunks of 1-20mb in size that are read very often and
written very rarely. You can pick a filesystem with options that
optimized for that. They're also non-data, so the root of that tree
has an entirely different backup priority than /etc or /home.

And then there are directories in /usr that don't exist in /. Are you
gonna link them too? So we have /share now? Or /src?

Seems to me that it makes less mess to move / to /usr than vice versa.
-- 
This email is:    [ ] actionable   [x] fyi        [ ] social
Response needed:  [ ] yes          [ ] up to you  [x] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] systemd installation location

[Mark David Dumlao]

On Mon, Sep 30, 2013 at 8:54 AM, Daniel Campbell <lists@sporkbox.us> wrote:
> I'm not affected by anything regarding the /usr switch, but I'd like
> to have a good talk with the first person who decided a
> system-critical binary belonged in /usr instead of /bin or /sbin.
> They've created a mess for every distro and any project that depends
> on their work.

(sorry for the previous post, accidentally clicked somewhere onscreen)

As I've pointed out before:
1) "system-critical" is actually dependent on the system. A system dependent
     on an smb share will find smbmount system critical. One dependent on
     zfs-fuse will find fuse system critical. With the advent of fuse,
some filesystem
     that depends on an arbitrary user program will find that system-critical.
     While this works for for 99.(99?)% of user systems out there, FHS
is supposed
     to be targetting all of them, and so it fails in principle in that respect.
     I remember making a lengthy thread on this mailing list challenging how FHS
     defined this and it appeared that nobody could make a defense.
2) the reality is, it's not just binaries even. There are some things
that binaries
    depend on, that in theory should be in /. For example, the hwid database, or
    libraries. Libraries make for a complex problem, because /usr is supposed to
    be network-sharable. Any libraries your programs depend on can't simply just
    be pushed to /, because then there'd be the chance that the
programs and their
    libraries were not in sync.

I made a handful of criticisms to FHS in that thread before, and nobody was
able to mount a suitable defense. The point being, even in principle, separating
/ and /usr is flaky design at best. That we just so happened to
accumulate a number
of packages that are historically installed to /usr is a consequence
of that. It's not
even necessarily the fault of the upstream developer, who's not
supposed to care so
much which PREFIX they install to, or the distro packager, who can't yet predict
how the user will tailor their system.

If you were in the shoes of the ebuild packagers, you would be hard-pressed to
predict which packages belong in the / PREFIX and which ones in /usr PREFIX,
100 times out of 100. But you need 100 times out of 100 or you'll get
people whining
that they can't boot or whining that they need to do some migration. That's
why / and /usr separation is broken.
-- 
This email is:    [ ] actionable   [x] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] systemd installation location

[Daniel Campbell]

On 09/29/2013 08:40 PM, Mark David Dumlao wrote:
> On Mon, Sep 30, 2013 at 8:54 AM, Daniel Campbell <lists@sporkbox.us> wrote:
>> I'm not affected by anything regarding the /usr switch, but I'd like
>> to have a good talk with the first person who decided a
>> system-critical binary belonged in /usr instead of /bin or /sbin.
>> They've created a mess for every distro and any project that depends
>> on their work.
> 
> (sorry for the previous post, accidentally clicked somewhere onscreen)
> 
> As I've pointed out before:
> 1) "system-critical" is actually dependent on the system. A system dependent
>      on an smb share will find smbmount system critical. One dependent on
>      zfs-fuse will find fuse system critical. With the advent of fuse,
> some filesystem
>      that depends on an arbitrary user program will find that system-critical.
>      While this works for for 99.(99?)% of user systems out there, FHS
> is supposed
>      to be targetting all of them, and so it fails in principle in that respect.
>      I remember making a lengthy thread on this mailing list challenging how FHS
>      defined this and it appeared that nobody could make a defense.
> 2) the reality is, it's not just binaries even. There are some things
> that binaries
>     depend on, that in theory should be in /. For example, the hwid database, or
>     libraries. Libraries make for a complex problem, because /usr is supposed to
>     be network-sharable. Any libraries your programs depend on can't simply just
>     be pushed to /, because then there'd be the chance that the
> programs and their
>     libraries were not in sync.
Libraries were one of my concerns when I was replying. I thought to
myself, "Well damn, won't shared libraries make this even more
difficult?" Perhaps it's a case for static-linked core binaries. :)

Anyway, I'm not in favor of FHS _per se_, but it sounds pretty
reasonable to have some semblance of order among where different parts
of a system go. Shoving everything into /usr and symlinking everything
else seems like a stop-gap or good-enough solution that came about due
to ignoring the existing standard (FHS) and refusing to try to change
it. I could be wrong, though. My point is I'm not dogmatic about it; I
just think that if the FOSS community were willing, a better solution
could be crafted.
> 
> I made a handful of criticisms to FHS in that thread before, and nobody was
> able to mount a suitable defense. The point being, even in principle, separating
> / and /usr is flaky design at best. That we just so happened to
> accumulate a number
> of packages that are historically installed to /usr is a consequence
> of that. It's not
> even necessarily the fault of the upstream developer, who's not
> supposed to care so
> much which PREFIX they install to, or the distro packager, who can't yet predict
> how the user will tailor their system.
> 
> If you were in the shoes of the ebuild packagers, you would be hard-pressed to
> predict which packages belong in the / PREFIX and which ones in /usr PREFIX,
> 100 times out of 100. But you need 100 times out of 100 or you'll get
> people whining
> that they can't boot or whining that they need to do some migration. That's
> why / and /usr separation is broken.
> 
I agree, but perhaps the / and /usr separation is a symptom of a greater
problem instead of being the problem in and of itself. Like Inception,
maybe we need to go further. :P

Re: [gentoo-user] systemd installation location

[Mark David Dumlao]

On Mon, Sep 30, 2013 at 9:50 AM, Daniel Campbell <lists@sporkbox.us> wrote:
> Anyway, I'm not in favor of FHS _per se_, but it sounds pretty
> reasonable to have some semblance of order among where different parts
> of a system go. Shoving everything into /usr and symlinking everything
> else seems like a stop-gap or good-enough solution that came about due
> to ignoring the existing standard (FHS) and refusing to try to change
> it. I could be wrong, though. My point is I'm not dogmatic about it; I
> just think that if the FOSS community were willing, a better solution
> could be crafted.

It's true that it's nice to have a semblance of order where different parts go.
But "all libraries and binaries in /usr" is also a semblance of order. You don't
separate stuff for the sake of separating stuff. You separate them because you
have a good reason to separate them. It turns out that there isn't a good reason
to separate them, and that there's no way to predictably separate them.

Mushing them together isn't just a stop-gap or good-enough solution. The
idea of keeping system-critical separate from non-critical was not maintainable
in the long run to begin with.

>> If you were in the shoes of the ebuild packagers, you would be hard-pressed to
>> predict which packages belong in the / PREFIX and which ones in /usr PREFIX,
>> 100 times out of 100. But you need 100 times out of 100 or you'll get
>> people whining
>> that they can't boot or whining that they need to do some migration. That's
>> why / and /usr separation is broken.
>>
> I agree, but perhaps the / and /usr separation is a symptom of a greater
> problem instead of being the problem in and of itself. Like Inception,
> maybe we need to go further. :P

The greater problem is what I'm pointing out already. Even in principle, you
just can't predict which files belong in /. It's always been a case-by-case,
system-by-system thing, and it just so happens that 99.9xxx% of the cases
are the same. Distro packagers, however, have to decide for 100% of the cases.
So they're going to end up making weird decisions that are easy for you to
second-guess but are actually tough.

If you want to solve the "hard problem", you want to create a tool that
will automate / and /usr migrations. Portage has to be aware of the tool
and maybe 100% of ebuilds will have to be rewritten to take advantage of the
dynamic prefixes set by the tool. That solves it for good, and you can have
your / and /usr separate. But only for gentoo.

Every package manager needs to have a similar tool and similar intelligence
for that to work.
-- 
This email is:    [ ] actionable   [x] fyi        [x] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] systemd installation location

[Daniel Campbell]

On 09/29/2013 09:05 PM, Mark David Dumlao wrote:
> On Mon, Sep 30, 2013 at 9:50 AM, Daniel Campbell <lists@sporkbox.us> wrote:
>> Anyway, I'm not in favor of FHS _per se_, but it sounds pretty
>> reasonable to have some semblance of order among where different parts
>> of a system go. Shoving everything into /usr and symlinking everything
>> else seems like a stop-gap or good-enough solution that came about due
>> to ignoring the existing standard (FHS) and refusing to try to change
>> it. I could be wrong, though. My point is I'm not dogmatic about it; I
>> just think that if the FOSS community were willing, a better solution
>> could be crafted.
> 
> It's true that it's nice to have a semblance of order where different parts go.
> But "all libraries and binaries in /usr" is also a semblance of order. You don't
> separate stuff for the sake of separating stuff. You separate them because you
> have a good reason to separate them. It turns out that there isn't a good reason
> to separate them, and that there's no way to predictably separate them.
> 
> Mushing them together isn't just a stop-gap or good-enough solution. The
> idea of keeping system-critical separate from non-critical was not maintainable
> in the long run to begin with.
> 
If separating them was unmaintainable, why bother with /bin and /sbin at
all, then? If /usr is essentially replacing what / was originally, it's
hard to take any filesystem standard seriously and we return to chaos.
What was /usr's original purpose? I'm not really in favor of the
separation or the merging; I'm in favor of what makes sense. For now,
shoving things into /usr is practical because most other software does
it. But that's following a trend. It's become *de facto* standard
instead of a well-designed, well-reasoned standard. If the change to
/usr was brought about because the FHS has holes in it, why not draft a
new FHS completely from the ground up? Sometimes a vast rewrite is
necessary in a standard, and the new standard could address modern
challenges.

>>> If you were in the shoes of the ebuild packagers, you would be hard-pressed to
>>> predict which packages belong in the / PREFIX and which ones in /usr PREFIX,
>>> 100 times out of 100. But you need 100 times out of 100 or you'll get
>>> people whining
>>> that they can't boot or whining that they need to do some migration. That's
>>> why / and /usr separation is broken.
>>>
>> I agree, but perhaps the / and /usr separation is a symptom of a greater
>> problem instead of being the problem in and of itself. Like Inception,
>> maybe we need to go further. :P
> 
> The greater problem is what I'm pointing out already. Even in principle, you
> just can't predict which files belong in /. It's always been a case-by-case,
> system-by-system thing, and it just so happens that 99.9xxx% of the cases
> are the same. Distro packagers, however, have to decide for 100% of the cases.
> So they're going to end up making weird decisions that are easy for you to
> second-guess but are actually tough.
> 
> If you want to solve the "hard problem", you want to create a tool that
> will automate / and /usr migrations. Portage has to be aware of the tool
> and maybe 100% of ebuilds will have to be rewritten to take advantage of the
> dynamic prefixes set by the tool. That solves it for good, and you can have
> your / and /usr separate. But only for gentoo.
> 
> Every package manager needs to have a similar tool and similar intelligence
> for that to work.
> 
I agree, but I don't see a tool like that coming up. Enforcing a /usr
merge and in edge cases forcing initramfs is the right *practical*
solution, but I don't think it solves the greater problem, which is
social and organizational. It may not even be a solvable problem, given
how vast and diverse the FOSS world is. But maybe discussion on it can
still be insightful, even if it can't be fruitful.

Re: [gentoo-user] systemd installation location

[Mark David Dumlao]

On Mon, Sep 30, 2013 at 10:15 AM, Daniel Campbell <lists@sporkbox.us> wrote:
> On 09/29/2013 09:05 PM, Mark David Dumlao wrote:
>> On Mon, Sep 30, 2013 at 9:50 AM, Daniel Campbell <lists@sporkbox.us> wrote:
>>> Anyway, I'm not in favor of FHS _per se_, but it sounds pretty
>>> reasonable to have some semblance of order among where different parts
>>> of a system go. Shoving everything into /usr and symlinking everything
>>> else seems like a stop-gap or good-enough solution that came about due
>>> to ignoring the existing standard (FHS) and refusing to try to change
>>> it. I could be wrong, though. My point is I'm not dogmatic about it; I
>>> just think that if the FOSS community were willing, a better solution
>>> could be crafted.
>>
>> It's true that it's nice to have a semblance of order where different parts go.
>> But "all libraries and binaries in /usr" is also a semblance of order. You don't
>> separate stuff for the sake of separating stuff. You separate them because you
>> have a good reason to separate them. It turns out that there isn't a good reason
>> to separate them, and that there's no way to predictably separate them.
>>
>> Mushing them together isn't just a stop-gap or good-enough solution. The
>> idea of keeping system-critical separate from non-critical was not maintainable
>> in the long run to begin with.
>>
> If separating them was unmaintainable, why bother with /bin and /sbin at
> all, then? If /usr is essentially replacing what / was originally, it's
> hard to take any filesystem standard seriously and we return to chaos.

The people that write software and systems and standards, etc are human. Give
them a break. They did the best they could.

> What was /usr's original purpose?
/usr was originally the home directory. Programs were moved there because
Unix didn't fit into a single disk.

http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

> If the change to
> /usr was brought about because the FHS has holes in it, why not draft a
> new FHS completely from the ground up?

At the end of the day, a standard is just a doc that people don't read. Part of
the reason why FHS was "successful" was because it was more than just a
prescriptive standard. Most of the rules in it had rationales written based
on existing practices.

In other words, writing a new FHS isn't going to do a damned thing to fix
the problems people have had so far, and there's the likelihood that people
won't follow it anyways. Heck, just look at /usr/portage. Portage, or at least
the distfiles, in no way, shape, or form, belongs in /usr. It's just
there because
that's how it was done before.

THE way to rewrite FHS is to change existing practice. And if the big distros
agree on it, the existing practice gets codified into a standard.

-- 
This email is:    [ ] actionable   [x] fyi        [ ] social
Response needed:  [ ] yes          [ ] up to you  [x] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none

Re: [gentoo-user] systemd installation location

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 457 bytes --]

On Mon, 30 Sep 2013 10:42:37 +0800, Mark David Dumlao wrote:

> > What was /usr's original purpose?  
> /usr was originally the home directory. Programs were moved there
> because Unix didn't fit into a single disk.
> 
> http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

Thanks for that link, it does a good job of explaining how we got in this
mess.


-- 
Neil Bothwick

I spilled Spot remover on my dog. Now he's gone.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] systemd installation location

[pk]

On 2013-09-30 04:05, Mark David Dumlao wrote:

> It's true that it's nice to have a semblance of order where different parts go.
> But "all libraries and binaries in /usr" is also a semblance of order. You don't
> separate stuff for the sake of separating stuff. You separate them because you
> have a good reason to separate them. It turns out that there isn't a good reason
> to separate them, and that there's no way to predictably separate them.
> 
> Mushing them together isn't just a stop-gap or good-enough solution. The
> idea of keeping system-critical separate from non-critical was not maintainable
> in the long run to begin with.

So what you're saying is that everything in /usr is system-critical? I
have gimp installed in /usr... I don't see a need to start gimp at boot
time. Maybe we should classify frozen-bubble as system-critical as well
(it's also in /usr)?

Seriously, boot-critical would be something that the system cannot *boot
without*, which belongs in /. Everything else should be in /usr, i.e.
non-boot-critical. How hard is it to start *non-boot* (system) critical
*after* boot (things like sshd)? I do that today...

> are the same. Distro packagers, however, have to decide for 100% of the cases.
> So they're going to end up making weird decisions that are easy for you to
> second-guess but are actually tough.

That's only true for binary distros.

> If you want to solve the "hard problem", you want to create a tool that
> will automate / and /usr migrations. Portage has to be aware of the tool

What's wrong with using autotools? I really don't see why you need it to
be dynamic. In Gentoo you install stuff once for every version (or if
you change use flag). Why invent stuff/complicate matters when you don't
need to?

Best regards

Peter K

Re: [gentoo-user] systemd installation location

[Alan McKinnon]

On 30/09/2013 08:24, pk wrote:
> So what you're saying is that everything in /usr is system-critical? I
> have gimp installed in /usr... I don't see a need to start gimp at boot
> time. Maybe we should classify frozen-bubble as system-critical as well
> (it's also in /usr)?
> 
> Seriously, boot-critical would be something that the system cannot *boot
> without*, which belongs in /. Everything else should be in /usr, i.e.
> non-boot-critical. How hard is it to start *non-boot* (system) critical
> *after* boot (things like sshd)? I do that today...

That is over-simplifying the problem and trivializing it. No-one ever
said the *everythign* in /usr is criticial for boot.

This is the problem:

a. There exists code used at boot and early-user space time. It is
critical that this code is available when needed.
b. One cannot predict with absolute certainty 100% of the time what
exactly that critical code is.
c. many reasonable setups turn out to have such critical code in /usr,
and this cannot be reliably predicted in advance

Your second paragraph reveals that you beleive you already know
everything you need to have to boot your system. Now do the same for
every possible Gentoo user out there and have it work 100% of the time
in ALL valid cases.

Do you now see the problem and the fulls cope and impact of it?


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] systemd installation location

[pk]

On 2013-09-30 08:45, Alan McKinnon wrote:

> That is over-simplifying the problem and trivializing it. No-one ever
> said the *everythign* in /usr is criticial for boot.

Is it really over-simplyfying it? How am I supposed to know whatever
comes next? Someone ("upstream") *may* find it boot-critical to have
'Space Invaders' operational during boot. Yes, I say that somewhat
*tounge-in-cheek* but the way things are going I'm not so sure anymore...

> This is the problem:
> 
> a. There exists code used at boot and early-user space time. It is
> critical that this code is available when needed.

I fully understand this and *if* I ever were to install code that I
*knew* had this dependency I would take a serious look if I really
*need* it and only then install it. But it would be up to me to make
that decision and take the necessary steps.

> b. One cannot predict with absolute certainty 100% of the time what
> exactly that critical code is.

In a general manner, no, you are correct... Also, see above
("Invaders")... (And if you don't understand what I'm trying to say, I'm
saying this is as *arbitrary* as it gets - which you, like me, seem to
be opposed to["arbitrariness"])

> c. many reasonable setups turn out to have such critical code in /usr,
> and this cannot be reliably predicted in advance

So I avoid things like Gnome, pulseaudio, systemd and similar stuff like
the plague but I *still* shall be forced to use whatever is dictated by
these things[1]? Don't get me wrong, if anyone wants to install Gnome or
whatever then they should have the restrictions required by it.

> Your second paragraph reveals that you beleive you already know
> everything you need to have to boot your system. Now do the same for
> every possible Gentoo user out there and have it work 100% of the time
> in ALL valid cases.

I *do* know everything I need to have to boot my system. I carefully
select my hardware and I take particular care of how I set up my system
thank you very much. But apparently my system is no longer deemed a
"valid case"... so I'm obviously not a "possible Gentoo user" anymore.

> Do you now see the problem and the fulls cope and impact of it?

I've seen it since *long* before this thread started. The main problem
is lack of resources (because of stupid decisions upstream which puts a
burden on Gentoo devs) and I can't (currently) help much with that other
than through monetary means (donations) but since Gentoo seems to go the
way of the dodo for me (or "assimilated" if you will) then I will take
my leave. For a while now it has only been inertia keeping me here. Or
maybe a hope that things will get better...

[1] And no, I'm not blaming systemd, Gnome or any of the other "pests"
in particular for this...

Best regards

Peter K

Re: [gentoo-user] systemd installation location

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]

On Tue, 01 Oct 2013 00:14:55 +0200, pk wrote:

> > Your second paragraph reveals that you beleive you already know
> > everything you need to have to boot your system. Now do the same for
> > every possible Gentoo user out there and have it work 100% of the time
> > in ALL valid cases.  
> 
> I *do* know everything I need to have to boot my system. I carefully
> select my hardware and I take particular care of how I set up my system
> thank you very much. But apparently my system is no longer deemed a
> "valid case"... so I'm obviously not a "possible Gentoo user" anymore.

Actually you are. No one said that your setup would no longer work, only
that it would no longer be supported by the devs. Since you know exactly
what you want and how to get it, that shouldn't be a problem as you
support it yourself.

Come November you will be running an unsupported setup, just like I am
now and have been for most of this year. But my system hasn't stopped
working. Well it did once and I had to fix it myself, that's all.


-- 
Neil Bothwick

"A computer is like an Old Testament god, with a lot of rules and no
mercy." -- Joseph Campbell

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] systemd installation location

[Alan McKinnon]

On 01/10/2013 00:14, pk wrote:
> On 2013-09-30 08:45, Alan McKinnon wrote:
> 
>> That is over-simplifying the problem and trivializing it. No-one ever
>> said the *everythign* in /usr is criticial for boot.
> 
> Is it really over-simplyfying it? How am I supposed to know whatever
> comes next? Someone ("upstream") *may* find it boot-critical to have
> 'Space Invaders' operational during boot. Yes, I say that somewhat
> *tounge-in-cheek* but the way things are going I'm not so sure anymore...

There are many examples in /usr you could have used to illustrate your
point, such as many fuse modules. And yet you chose an imaginary space
invader game.

Let's rather stick within the bounds of what is feasible, OK?

>> This is the problem:
>>
>> a. There exists code used at boot and early-user space time. It is
>> critical that this code is available when needed.
> 
> I fully understand this and *if* I ever were to install code that I
> *knew* had this dependency I would take a serious look if I really
> *need* it and only then install it. But it would be up to me to make
> that decision and take the necessary steps.

But it's not just you. You are not running LFS, you are running Gentoo.
It has ebuilds and ebuilds put the generated files somewhere, and that
destination is the same for every user of that ebuild.

Unix, by design and unlike a traditional mainframe OS, does not
distinguish between different types of files and does limit where you
can put files. This has two consequences - you can do virtually anything
you like with it as everything is a file, and filesystem files and
structure have been moved out to human space in the hands of the
sysadmin/packager/maintainer/user or whatever. Some sanity must prevail.

The Linux boot process can conceivably run any arbitrary code it needs
to run to get userspace into a runnable state. This can easily be code
that we haven't conceived of yet and becuase it is Unix, it could reside
anywhere. Also because it's Unix and because sysadmins have learned over
the years we constrain ourselves to putting the code in the bin, sbin
and lib directories in / and in /usr.

Clearly, there is a massive distinction between code there and in say
/opt or /var/lib, that is why you won't find boot-critical code there.
But there is no such clear distinction between / and /usr. What *you*
think is not boot critical may be criticial for someone else.

And here's the kicker:

You don't get to decide for the other guy. But the packager gets to
support him, and has to edit ebuilds to install all the necessary code
not in /usr but in /. And they have to do this over and over and over,
and while they are doing that they have to answer users like you who are
complinaing about unneccessary rebuilds just to change the desitnation
of a few files.

This is a no-win-ever situation for devs and they have decided they are
not doing it anymore and have made a decision to not support separate
/usr without initramfs. that is their right as you do not pay them a salary.

This is the correct decision for Gentoo to have made, as the problem is
open ended and is never completed, plus there is no clear distinction
between what is boot critical in the general case and what is not. if
you can't see or understand that, then we have nothing more to discuss.

If you don't like what Gentoo has done then I recommend you take it like
a man and fork. Assume the maintenanceburden yourself.


> 
>> b. One cannot predict with absolute certainty 100% of the time what
>> exactly that critical code is.
> 
> In a general manner, no, you are correct... Also, see above
> ("Invaders")... (And if you don't understand what I'm trying to say, I'm
> saying this is as *arbitrary* as it gets - which you, like me, seem to
> be opposed to["arbitrariness"])
> 
>> c. many reasonable setups turn out to have such critical code in /usr,
>> and this cannot be reliably predicted in advance
> 
> So I avoid things like Gnome, pulseaudio, systemd and similar stuff like
> the plague but I *still* shall be forced to use whatever is dictated by
> these things[1]? Don't get me wrong, if anyone wants to install Gnome or
> whatever then they should have the restrictions required by it.
> 
>> Your second paragraph reveals that you beleive you already know
>> everything you need to have to boot your system. Now do the same for
>> every possible Gentoo user out there and have it work 100% of the time
>> in ALL valid cases.
> 
> I *do* know everything I need to have to boot my system. I carefully
> select my hardware and I take particular care of how I set up my system
> thank you very much. But apparently my system is no longer deemed a
> "valid case"... so I'm obviously not a "possible Gentoo user" anymore.
> 
>> Do you now see the problem and the fulls cope and impact of it?
> 
> I've seen it since *long* before this thread started. The main problem
> is lack of resources (because of stupid decisions upstream which puts a
> burden on Gentoo devs) and I can't (currently) help much with that other
> than through monetary means (donations) but since Gentoo seems to go the
> way of the dodo for me (or "assimilated" if you will) then I will take
> my leave. For a while now it has only been inertia keeping me here. Or
> maybe a hope that things will get better...
> 
> [1] And no, I'm not blaming systemd, Gnome or any of the other "pests"
> in particular for this...
> 
> Best regards
> 
> Peter K
> 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] systemd installation location

[pk]

On 2013-10-01 08:16, Alan McKinnon wrote:

> There are many examples in /usr you could have used to illustrate your
> point, such as many fuse modules. And yet you chose an imaginary space
> invader game.
> 
> Let's rather stick within the bounds of what is feasible, OK?

What can I say, I like to exaggerate... :-)
But it seems you got my point. Although I would not rule out "Space
Invaders" as either imaginary (it came out in 1978) nor infeasible (at
boot).

> But it's not just you. You are not running LFS, you are running Gentoo.
> It has ebuilds and ebuilds put the generated files somewhere, and that
> destination is the same for every user of that ebuild.

Which is why I said what I said further down in the mail you replied to...

> Unix, by design and unlike a traditional mainframe OS, does not
> distinguish between different types of files and does limit where you
> can put files. This has two consequences - you can do virtually anything
> you like with it as everything is a file, and filesystem files and
> structure have been moved out to human space in the hands of the
> sysadmin/packager/maintainer/user or whatever. Some sanity must prevail.

Yes, sanity is what I'm after but it seems I'm in the minority...

> The Linux boot process can conceivably run any arbitrary code it needs
> to run to get userspace into a runnable state. This can easily be code
> that we haven't conceived of yet and becuase it is Unix, it could reside
> anywhere. Also because it's Unix and because sysadmins have learned over
> the years we constrain ourselves to putting the code in the bin, sbin
> and lib directories in / and in /usr.
> 
> Clearly, there is a massive distinction between code there and in say
> /opt or /var/lib, that is why you won't find boot-critical code there.
> But there is no such clear distinction between / and /usr. What *you*
> think is not boot critical may be criticial for someone else.

I couldn't agree more. However, since some devs (and I don't mean anyone
in particular) have started to expect /usr to always be available for
"boot-critical" software then what is to say that the next one *will*
require /opt and/or /var/lib at boot time? And where do we make a
distinction between a boot-critical thing and a non-boot-critical thing.
For all I know there may actually be someone out there seriously
considering adding "Space Invaders" as a boot thing for, say sysops that
want to reboot a really big server and want to play while booting... I'm
only kidding of course and hope noone takes this seriously!? ;-)

> And here's the kicker:
> 
> You don't get to decide for the other guy. But the packager gets to
> support him, and has to edit ebuilds to install all the necessary code
> not in /usr but in /. And they have to do this over and over and over,
> and while they are doing that they have to answer users like you who are
> complinaing about unneccessary rebuilds just to change the desitnation
> of a few files.
> 
> This is a no-win-ever situation for devs and they have decided they are
> not doing it anymore and have made a decision to not support separate
> /usr without initramfs. that is their right as you do not pay them a salary.
> 
> This is the correct decision for Gentoo to have made, as the problem is
> open ended and is never completed, plus there is no clear distinction
> between what is boot critical in the general case and what is not. if
> you can't see or understand that, then we have nothing more to discuss.
> 
> If you don't like what Gentoo has done then I recommend you take it like
> a man and fork. Assume the maintenanceburden yourself.

I've already come to that conclusion myself (as, again, I mentioned in
my mail further down).

Bye, so long and thanks for the f*sh!

Best regards

Peter K

[gentoo-user] Re: systemd installation location

[Martin Vaeth]

pk <peterk2@coolmail.se> wrote:
>
> Seriously, boot-critical would be something that the system cannot *boot
> without*, which belongs in /. Everything else should be in /usr, i.e.
> non-boot-critical. How hard is it to start *non-boot* (system) critical
> *after* boot (things like sshd)? I do that today...

For somebody who uses sshfs-fuse to mount /usr from another machine,
sshd and fuse *are* boot critical. (And yes, this maybe a natural
setup for home systems since in many settings this is more secure
than using nfs for this.)

But even without net-mounting the answer to "how hard is it to start ...
after boot" the answer for modern kernels is: a lot.
Modern kernels initialize modules simulataneously (i.e. in an
unpredictable order). So you would have to remember and postpone these
initializations which can produce all sorts of unexpected problems
if you have complicated implicit dependencies.
Older versions of udev did this in a somewhat primitive way
(restarting failed services again), but obviously this is not
a clean solution (since the failing could have other reasons).

Re: [gentoo-user] systemd installation location

[Mark David Dumlao]

On Mon, Sep 30, 2013 at 2:24 PM, pk <peterk2@coolmail.se> wrote:
> On 2013-09-30 04:05, Mark David Dumlao wrote:
>> are the same. Distro packagers, however, have to decide for 100% of the cases.
>> So they're going to end up making weird decisions that are easy for you to
>> second-guess but are actually tough.
>
> That's only true for binary distros.

That is not true. Even in source-based distros like gentoo, distro packagers
decide where the files go. So far, it's only in a completely from scratch *nix
environment where the end user gets to decide where files go.

And "where do the files go" is pretty much what made this problem be apparent.
Many packages with udev rules depend on programs, resources, libraries in /usr.
It is _not_ trivial to fix those packages. If _you_ think it is, I recommend you
replace the entire gentoo bugzilla community because you are clearly a
rockstar bugfixer.

>
>> If you want to solve the "hard problem", you want to create a tool that
>> will automate / and /usr migrations. Portage has to be aware of the tool
>
> What's wrong with using autotools? I really don't see why you need it to
> be dynamic. In Gentoo you install stuff once for every version (or if
> you change use flag). Why invent stuff/complicate matters when you don't
> need to?
>

You do not really understand the scope of the problem.

The problem is that "boot critical" is subjective to the system. A program that
is "boot critical" for one system may not be "boot critical" for another. But
where software gets installed is generally "hard coded" into packages
(defaulting to /usr). That is the status quo.

Because of this, the package manager simply does not have enough
information on whether a package is boot critical or not. It is not part of
the ebuild. It is not part of the emerge switches. Not only that, whether a
package is boot critical or not could change at any time. nfs-utils are only
boot critical if you use nfs. ssh is only boot critical if you use sshfs.
Perl is only boot critical if you have a startup script that counts the number
of virgins you've sacrificed to the goat god. Making a filesystem boot-critical
is something that the package manager does not and cannot track. Autotools
also cannot track it as it happens outside of compile time.

If you want the / and /usr separation nonsense solved, you should write a
program that can "mark" a binary as boot-critical. It will then copy the binary
and all of its libraries to /, and copy and rebuild any dependencies into / as
well. It must be a full copy, otherwise the promise that /usr can be shared
will be violated. Everytime that package is rebuilt, it must be built and copied
into _both_ / and /usr. Your program should also be able to unmark a binary
as boot critical and thus delete any copies in /

Your program should be understood by portage, or at least run as a portage
hook. Copy paste that to all package managers as well.

What's more, any program depending on a boot critical program must be
rewritten so that it looks for the program in the correct path. For backwards
compatibility, a "boot critical" program should generate\ symlinks in the
/ filesystem's /usr tree (the normally empty directory shadowed by the /usr
filesystem), so that if the /usr filesystem is not available any programs
depending on that program would still work.

That program is writable in theory. It's VERY tedious to write it, much less
test that it works.
-- 
This email is:    [ ] actionable   [x] fyi        [ ] social
Response needed:  [ ] yes          [x] up to you  [ ] no
Time-sensitive:   [ ] immediate    [ ] soon       [x] none