[gentoo-user] some of the stuff in /usr that's become a problem

[gentoo-user] some of the stuff in /usr that's become a problem

[Greg Woodbury]

One of the most obvious things that broke booting with a seperate /usr 
is not GNOMEs fault, but GRUB 2's fault.

the move of /bin to /usr/bin (for things like cp,mv,ln,ls) came after 
the breakage of /usr, but is symptomatic of some distros cavalier 
attitudes to the problem.

/usr/lib/udev.....
/usr/lib/systemd.....

were both placed in /usr despite objections from a number of folks.

So claims that udev and systemd are not responsible are not true.

/usr/lib/e2initrd-helper was placed in /usr despite objections.
/usr/lib/libdevmapper* was moved despite objections...
/usr/lib/liblvm2* helpers were placed in /usr despite objections...

There were deliberate placements of "new" or updated libraries in /usr 
that were known ahead of time that would break the use of a separate
/usr filesystem.

It was pointed out quite plainly at the time, and the placements were 
made anyway, dismissing the concerns are "mere historical artifacts" or 
"clinging to ancient and outmoded traditions."

The *same things* are still being cited (about being outmoded) in 
dismissing concers about forcing useres to adopt technologies they do 
not want to use.

Re: [gentoo-user] some of the stuff in /usr that's become a problem

[Daniel Campbell]

On 09/29/2013 09:03 PM, Greg Woodbury wrote:
> One of the most obvious things that broke booting with a seperate /usr
> is not GNOMEs fault, but GRUB 2's fault.
> 
> the move of /bin to /usr/bin (for things like cp,mv,ln,ls) came after
> the breakage of /usr, but is symptomatic of some distros cavalier
> attitudes to the problem.
> 
> /usr/lib/udev.....
> /usr/lib/systemd.....
> 
> were both placed in /usr despite objections from a number of folks.
> 
> So claims that udev and systemd are not responsible are not true.
> 
> /usr/lib/e2initrd-helper was placed in /usr despite objections.
> /usr/lib/libdevmapper* was moved despite objections...
> /usr/lib/liblvm2* helpers were placed in /usr despite objections...
> 
> There were deliberate placements of "new" or updated libraries in /usr
> that were known ahead of time that would break the use of a separate
> /usr filesystem.
> 
> It was pointed out quite plainly at the time, and the placements were
> made anyway, dismissing the concerns are "mere historical artifacts" or
> "clinging to ancient and outmoded traditions."
> 
> The *same things* are still being cited (about being outmoded) in
> dismissing concers about forcing useres to adopt technologies they do
> not want to use.
> 
I agree with you but I think the distinction made on udev and systemd is
that their *upstreams* didn't suggest they go in /usr. I don't know for
sure since I don't follow systemd and frankly detest it, but if they
said systemd and udev belong in /bin or somesuch, then they can't be
held responsible. The responsibility for that decision falls on the
maintainers, but it's compounded by the dependencies of systemd/udev.
They depend on dbus, which resides in /usr. Was that an upstream
decision or a distro decision? If we follow this dependency tree of /usr
moves, which package was the first to migrate to /usr and begin this
problem? The move to /usr was a social one that started years ago, not a
technical decision made this year. The issue right now is damage control
and, for some, maybe taking a good look at the FHS and deciding what
really makes sense.

[gentoo-user] Re: some of the stuff in /usr that's become a problem

[»Q«]

On Sun, 29 Sep 2013 22:03:11 -0400
Greg Woodbury <redwolfe@gmail.com> wrote:

> One of the most obvious things that broke booting with a
> seperate /usr is not GNOMEs fault, but GRUB 2's fault.
> 
> the move of /bin to /usr/bin (for things like cp,mv,ln,ls) came after 
> the breakage of /usr, but is symptomatic of some distros cavalier 
> attitudes to the problem.
> 
> /usr/lib/udev.....
> /usr/lib/systemd.....
> 
> were both placed in /usr despite objections from a number of folks.
> 
> So claims that udev and systemd are not responsible are not true.
> 
> /usr/lib/e2initrd-helper was placed in /usr despite objections.
> /usr/lib/libdevmapper* was moved despite objections...
> /usr/lib/liblvm2* helpers were placed in /usr despite objections...
> 
> There were deliberate placements of "new" or updated libraries
> in /usr that were known ahead of time that would break the use of a
> separate /usr filesystem.
> 
> It was pointed out quite plainly at the time, and the placements were 
> made anyway, dismissing the concerns are "mere historical artifacts"
> or "clinging to ancient and outmoded traditions."

What were the reasons given for those changes at the time?  

Re: [gentoo-user] some of the stuff in /usr that's become a problem

[William Hubbs]

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

On Sun, Sep 29, 2013 at 09:21:01PM -0500, Daniel Campbell wrote:
> > /usr/lib/udev.....
> > /usr/lib/systemd.....
> > 
> > were both placed in /usr despite objections from a number of folks.
> > 
> > So claims that udev and systemd are not responsible are not true.

Udev is installed in / in gentoo. I am a co-maintainer of udev and that
was fixed quite some time back, it is the Gentoo systemd team that installs
their version of udev in /usr.

Installing udev or eudev, however, doesn't really solve the issue
though, because it is possible to run arbitrary programs from within
udev rules.

Another unrelated concern is if you install a program in / that needs to
access something in /usr/share, this will be broken by not having /usr
mounted. This means that, for example, the locale logic of most software
can't work without /usr since it accesses files in /usr/share/locale.

William


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

Re: [gentoo-user] some of the stuff in /usr that's become a problem

[Daniel Campbell]

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

On 09/29/2013 10:13 PM, William Hubbs wrote:
> On Sun, Sep 29, 2013 at 09:21:01PM -0500, Daniel Campbell wrote:
>>> /usr/lib/udev..... /usr/lib/systemd.....
>>> 
>>> were both placed in /usr despite objections from a number of
>>> folks.
>>> 
>>> So claims that udev and systemd are not responsible are not
>>> true.
> 
> Udev is installed in / in gentoo. I am a co-maintainer of udev and
> that was fixed quite some time back, it is the Gentoo systemd team
> that installs their version of udev in /usr.
> 
> Installing udev or eudev, however, doesn't really solve the issue 
> though, because it is possible to run arbitrary programs from
> within udev rules.
> 
> Another unrelated concern is if you install a program in / that
> needs to access something in /usr/share, this will be broken by not
> having /usr mounted. This means that, for example, the locale logic
> of most software can't work without /usr since it accesses files in
> /usr/share/locale.
> 
> William
> 
I believe you misquoted. Greg said those things; I was merely quoting
him. :)

You're right, though; it's a problem that lots of programs have. I
guess it's the natural result of modular software that has
interdependencies. You basically need *everything* available on boot.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSSPLCAAoJEJUrb08JgYgHFaEH/ietryULwNCbYdoLYFNJXoT1
vjecOzD0nKxY/dN26X5nZfBuuLkN/SARdrk/xqlp7Fw4UKEuP6XwcJWSoP2/o8t7
TxdlbqAAxNGytOpUlqZmJd53c3pivD11PS467Iy4UsRmpH0TbOerqESi9lR+X7bI
OR6ghVpOqkBrNjwNtSREOHjApjQ6h451bGHW2rHUUbOlzoOZYiIBCxBxsCYc/fEc
jS8LbNioj9BeipRFeIAqr+LPhpPDq7KE3EA/tcOb2WT5ro0yy6MAAdoBJSRKiFmI
woSKmEWgFVAa6eGJjTmTRTJjra0L9EWcxHSRDBBNuJTsV1AfMR8stRPD6+FUkaE=
=b8AN
-----END PGP SIGNATURE-----

Re: [gentoo-user] some of the stuff in /usr that's become a problem

[Neil Bothwick]

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

On Sun, 29 Sep 2013 22:03:11 -0400, Greg Woodbury wrote:

> One of the most obvious things that broke booting with a seperate /usr 
> is not GNOMEs fault, but GRUB 2's fault.

How so? All the files GRUB2 needs to boot are in /boot and GRUB is out of
the picture before the kernel loads or mounts /, let alone does anything
else.


-- 
Neil Bothwick

A positive attitude may not solve all your problems, but it will annoy
enough people to make it worth the effort.

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

Re: [gentoo-user] some of the stuff in /usr that's become a problem

[Greg Woodbury]

On 09/29/2013 11:13 PM, William Hubbs wrote:
> On Sun, Sep 29, 2013 at 09:21:01PM -0500, Daniel Campbell wrote:
>>> /usr/lib/udev.....
>>> /usr/lib/systemd.....
>>>
>>> were both placed in /usr despite objections from a number of folks.
>>>
>>> So claims that udev and systemd are not responsible are not true.
> 
> Udev is installed in / in gentoo. I am a co-maintainer of udev and that
> was fixed quite some time back, it is the Gentoo systemd team that installs
> their version of udev in /usr.
> 
> Installing udev or eudev, however, doesn't really solve the issue
> though, because it is possible to run arbitrary programs from within
> udev rules.
> 
> Another unrelated concern is if you install a program in / that needs to
> access something in /usr/share, this will be broken by not having /usr
> mounted. This means that, for example, the locale logic of most software
> can't work without /usr since it accesses files in /usr/share/locale.
> 
> William
> 
All that is required is that the programs and libraries necessary to
locate and mount root and then to find and mount other filesystems be in
root.  This was a fundamental piece of the design of UNIX and was
inherited by many UNIX derived systems.  While debugging System IV
systematizing, we had meetings with the folks from Murray Hill and they
insisted that this had to be maintained. (circa 1982)

The actual details of what has broken are not as important as the fact
that the breakage happened and complaints about the breakage have be
dismissed with disrespect and disparaging remarks about clinging to
ancient history.  That has been done at least twice in this set of threads.

Certainly, Linux is an evolving and growing system, but there seems to
be no natural selection process to cull the things that don't work.
Change is NOT the problem, without change there can be no progress.  But
to change something for no good reason, simply to change it, is not healthy.

-- 
G.Wolfe Woodbury
redwolfe@gmail.com

Re: [gentoo-user] some of the stuff in /usr that's become a problem

[Greg Woodbury]

On 09/29/2013 11:40 PM, Daniel Campbell wrote:

> You're right, though; it's a problem that lots of programs have. I
> guess it's the natural result of modular software that has
> interdependencies. You basically need *everything* available on boot.

You don't need everything (obviously -- otherwise dracut/init* would not
work)  Only the things necessary to get the system bootstrapped.

It occurs to me that anything dracut fetches from /usr/* to put in the
initrd is the stuff that has caused the breakage.

To me, the requirement for an initramfs/initrd is an admission of
failure.  Breaking the rules is what made it required.

-- 
G.Wolfe Woodbury
redwolfe@gmail.com

Re: [gentoo-user] some of the stuff in /usr that's become a problem

[Alan McKinnon]

On 01/10/2013 10:30, Greg Woodbury wrote:
> All that is required is that the programs and libraries necessary to
> locate and mount root and then to find and mount other filesystems be in
> root.


Please provide the full and complete list of all code on all Gentoo
systems that are required in all supported configurations to support
that end. Keep in mind you are dealing with an open-ended problem.

Then provide patches to all ebuilds that will move said code to /

Then provide a means by which any new code in the future can be detected
to fall into this same category and alert the develops before too much
breakage happens.

Those three sentences above are not facetious. That is exactly what you
are expecting the Gentoo maintainers to do. I don't think you grasp the
full extent of this problem on modern Linux systems, it is not just a
case of doing what you have to do to mount all other filesystems, it's a
case of finding everything the must happen to do that and enforcing that
none of it creeps into /usr. Which includes all manner of things users
might validly want to so, most of it that you and I have never thought of.

Recall how Unix treats everything as a file and lets you pipe, tee and
redirect data in wonderful ways to produce output not envisaged by tool
designers?

The start-up sequence on modern Linuxes is starting to lean heavily in
an analogous direction. The simple days of 1982 when everything in early
boot was predictable are long gone.

-- 
Alan McKinnon
alan.mckinnon@gmail.com