View previous topic :: View next topic |
Author |
Message |
spork_kitty Tux's lil' helper
Joined: 05 Jul 2019 Posts: 124
|
Posted: Sun Jul 21, 2019 1:54 pm Post subject: Gentoo seems to be chasing nu Linux design (/usr merge) |
|
|
Sources:
I hope the developers have the care and foresight to avoid foisting the nu Linux paradigm on their users. Merged /usr is less modular, typically requires an initramfs (adding more steps to kernel upgrades,), and is really only used by systemd and other software mistakenly placed in /usr like LUKS and LVM. (By extension, any mainstream distro like Fedora is already heavily invested in systemd tech due to it coming out of Red Hat) Every other init system and service manager can adapt to split /usr without issue, but systemd needs the entire package tree to change to suit it. That seems sane. /s
Please note metadata.xml information on all current init systems in Gentoo, and their maintainers:
sys-apps/openrc: openrc@gentoo.org (see https://wiki.gentoo.org/wiki/Project:OpenRC)
sys-apps/systemd: systemd@gentoo.org (see https://wiki.gentoo.org/wiki/Project:Systemd)
sys-apps/sysvinit: williamh@gentoo.org
sys-apps/s6: williamh@gentoo.org (member of Systemd team) + proxy maintainers
sys-apps/s6-linux-init: williamh@gentoo.org + proxy maintainers
sys-process/runit: williamh@gentoo.org
sys-apps/cinit: no maintainer
sys-apps/minit: no maintainer
Upstart is not in tree. Please list other init systems (and the result of `equery m <pkg>`) so we can get a better picture of what's going on. I listed the ones I could find.
From my vantage point, I see one person and/or team making policy to suit a single init system over others, mostly due to said init system being incapable of booting on split-usr systems. That sounds like a problem with upstream, who don't support split /usr at all.
This sort of stuff belongs in the systemd profiles, imo. If you don't think it belongs there I'd be interested in reading why.
What solutions do you guys plan on using to maintain your split /usr?
EDIT: qualified statements to appease nitpicks, bolded important part
Last edited by spork_kitty on Sun Jul 21, 2019 3:34 pm; edited 1 time in total |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6067 Location: Removed by Neddy
|
|
Back to top |
|
|
Anon-E-moose Watchman
Joined: 23 May 2008 Posts: 6160 Location: Dallas area
|
Posted: Sun Jul 21, 2019 2:21 pm Post subject: |
|
|
Just to be clear separate usr is fine, systemd is broken _________________ UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6067 Location: Removed by Neddy
|
Posted: Sun Jul 21, 2019 2:25 pm Post subject: |
|
|
hey, im not saying separate /usr isn't fine, i am just getting some info. If key applications (udev WHICH is a systemd application) store info or applications in /usr AND itself does not have the concept of "needed to boot" and "once things are booted" then yes there is an architectural flaw
I have said this time and time again with FOSS software (and software in general) there is no system engineering going on. no use cases, no sequence diagrams. every now and again you see BDD and IBD but none of the rational as to that
Had the system been modeled and a separate /usr been considered as a use-case then the pre-req would have been clear for the likes of udev (a systemd project) _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
mike155 Advocate
Joined: 17 Sep 2010 Posts: 4438 Location: Frankfurt, Germany
|
Posted: Sun Jul 21, 2019 2:59 pm Post subject: |
|
|
spork_kitty,
please stop posting bullshit!
Quote: | Merged /usr is less modular |
Why is it less modular?
Quote: | Merged /usr ... requires an initramfs |
Not true. I have /usr merged on some machines and I don't use initramfs.
Quote: | Merged /usr ... is really only used by systemd. |
Not true.
You don't seem to like merged /usr. That's fine. But it's not appropriate to spread FUD. |
|
Back to top |
|
|
spork_kitty Tux's lil' helper
Joined: 05 Jul 2019 Posts: 124
|
Posted: Sun Jul 21, 2019 3:17 pm Post subject: |
|
|
mike155 wrote: | spork_kitty,
please stop posting bullshit!
Quote: | Merged /usr is less modular |
Why is it less modular?
Quote: | Merged /usr ... requires an initramfs |
Not true. I have /usr merged on some machines and I don't use initramfs.
Quote: | Merged /usr ... is really only used by systemd. |
Not true.
You don't seem to like merged /usr. That's fine. But it's not appropriate to spread FUD. |
Merged /usr is less modular because it consolidates the system into a single dir. You might be able to finagle some mounts in subdirs of /usr (and pray the mount order is correct), but some people like being able to mount /usr (or other paths) over the network read-only, and still be able to boot without an initramfs.
Speaking of initramfs, perhaps I should qualify: If you need anything in /usr, you need an initramfs. That includes systemd, bluetooth at boot, FDE via LUKS+LVM, etc. If your machine doesn't require those things before services are brought up, then you don't need it.
If I'm spreading FUD then please provide (neutral) evidence to the contrary. I'm basing my information on personal experience in dealing with initramfs's and multiple distros that have followed this bone-headed move. It results in less flexible systems and it always seems to come back around to systemd when this sort of crap happens. Don't shoot the messenger. You can verify the information I shared yourself. |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 22717
|
Posted: Sun Jul 21, 2019 5:02 pm Post subject: |
|
|
This problem is exacerbated by two distinct major changes, both involving /usr. First, there was the "separate usr is broken" fiasco that systemd pushed (while carefully claiming they were just messengers reporting other people's brokenness), which Naib linked above. Various boot-important programs began assuming that they could access /usr during early boot, and rather than fix those assumptions, someone hit on the idea to require /usr be a directory on /, not mounted separately, or else you must use initramfs tricks to let the system pretend that /usr is not a separate mount. That happened years ago. It was disruptive and annoying, but that is mostly settled. Everyone who wants /usr to be a separate mount has adapted, whether by blacklisting the software that cannot handle it, using initramfs tricks to work around it, or giving up and moving /usr to /.
More recently[1], there has been another big disruptive change. This one advocates the equivalent of: Code: | cd /
for a in bin sbin; do
mv $a/* usr/$a/*
rmdir $a
ln -s usr/$a
done | That is: move every file from bin to usr/bin, every file from sbin to usr/sbin, then replace /bin and /sbin with symlinks to the corresponding directories in /usr. This new disruption goes by the name of "split-usr", which is confusing because the old separate-usr-is-broken led to a project called "usr merge" (merging /usr to /), and split-usr isn't undoing usr-merge. It's doing something new. To further confuse things, at least for me, systemd's page about Fedora combining /bin and /usr/bin refers to that project as usr-merge.
[1] I've only begun seeing this in the last year or so. The page Naib linked claims Fedora did this many releases ago. I guess they handled it without much noise spilling out into the things I read. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54586 Location: 56N 3W
|
Posted: Sun Jul 21, 2019 5:33 pm Post subject: |
|
|
spork_kitty,
spork_kitty wrote: | ... typically requires an initramfs (adding more steps to kernel upgrades,) |
Why?
My initrd is kernel agnostic. Its the user space tools I need to support root in LVM on top of raid5.
There are no kernel modules in there. Its just over 10 years old and it still works unchanged.
steveL provided a set of patches so that separate /usr continued to work.
They will not fix the /bin <-> /usr/bin merge. That's just Windowsesque _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6067 Location: Removed by Neddy
|
Posted: Sun Jul 21, 2019 5:43 pm Post subject: |
|
|
/usr was a hack to start with but the use cases it enabled have been viable.
It never ceases to amaze me how piss poor software engineer are at architecting a system... Critical to boot and that which can be delayed should have been understood and managed by now. This constant hack upon hack upon hack, initiated by systemd development, and perpetuated by a lack of understanding has gotten us where we are. _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
bunder Bodhisattva
Joined: 10 Apr 2004 Posts: 5937
|
Posted: Sun Jul 21, 2019 5:52 pm Post subject: |
|
|
that freedesktop article wrote: | Here's a short, very in-comprehensive list of software we are aware of that currently are not able to provide the full set of functionality when /usr is split off and not pre-mounted at boot: udev-pci-db/udev-usb-db and all rules depending on this (using the PCI/USB database in /usr/share), PulseAudio, NetworkManager, ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip, multipath, Argyll, VMWare, the locale logic of most programs and a lot of other stuff. |
all of which belongs in runlevel default, which runs after localmount which is in the boot runlevel... /shrug
edit: well, except for lvm _________________
Neddyseagoon wrote: | The problem with leaving is that you can only do it once and it reduces your influence. |
banned from #gentoo since sept 2017 |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54586 Location: 56N 3W
|
Posted: Sun Jul 21, 2019 6:01 pm Post subject: |
|
|
Naib.
The lack of systems design goes back much further in the PC world than systemd. systemd is just an example of a very long trend.
For an early example look at the introduction and growth oy hard drives and all the hacks that went into that.
The partition table was squeezed into 66 (unused) bytes at the end of the boot record as a hack to get around the MSDOS maximum file system size of 32MB.
That worked until HDD got to 128MB, as the partition table could only hold four entries.
Then the extended/logical partition was a hack grafted on to of the previous hack.
There was more to come ...
The BIOS could only read the first 528MB af a HDD. Thus the /boot at the front of the volume hack was introduced
The problem with the BIOS only being able to read part of a HDD has been repeated several times since.
33G and 137G limits come to mind.
Its not all software either ... why did early PCs ship with a dummy load on the 12v?
It was to keep the early switch mode PSUs regulating properly when no HDD was fitted.
There are lots more.
On the other hand, when Intel actually tried to do it properly, from a systems perspective, and drop all the legacy cruft, we had the Itanium, which nobody wanted because it was not legacy code compatible. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Anon-E-moose Watchman
Joined: 23 May 2008 Posts: 6160 Location: Dallas area
|
Posted: Sun Jul 21, 2019 6:05 pm Post subject: |
|
|
bunder wrote: | that freedesktop article wrote: | Here's a short, very in-comprehensive list of software we are aware of that currently are not able to provide the full set of functionality when /usr is split off and not pre-mounted at boot: udev-pci-db/udev-usb-db and all rules depending on this (using the PCI/USB database in /usr/share), PulseAudio, NetworkManager, ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip, multipath, Argyll, VMWare, the locale logic of most programs and a lot of other stuff. |
|
and I don't use any of that stuff
Quote: | all of which belongs in runlevel default, which runs after localmount which is in the boot runlevel... /shrug
edit: well, except for lvm |
Indeed, do you need PA, NM, MM, udisks, etc when "booting" not at runtime, but boot time.
And if dbus is needed for booting (for the sys-d crowd) then it shouldn't be in /usr,
as far as udev, it worked quite well without /usr being mounted, before sys-d subsumed it.
All the brouhaha is brought about by RH's insane desire to be the MS of the linux world, and thinking they have to emulate it at that. _________________ UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6067 Location: Removed by Neddy
|
Posted: Sun Jul 21, 2019 6:12 pm Post subject: |
|
|
NeddySeagoon wrote: | Naib.
The lack of systems design goes back much further in the PC world than systemd. systemd is just an example of a very long trend.
For an early example look at the introduction and growth oy hard drives and all the hacks that went into that.
The partition table was squeezed into 66 (unused) bytes at the end of the boot record as a hack to get around the MSDOS maximum file system size of 32MB.
That worked until HDD got to 128MB, as the partition table could only hold four entries.
Then the extended/logical partition was a hack grafted on to of the previous hack.
There was more to come ...
The BIOS could only read the first 528MB af a HDD. Thus the /boot at the front of the volume hack was introduced
The problem with the BIOS only being able to read part of a HDD has been repeated several times since.
33G and 137G limits come to mind.
Its not all software either ... why did early PCs ship with a dummy load on the 12v?
It was to keep the early switch mode PSUs regulating properly when no HDD was fitted.
There are lots more.
On the other hand, when Intel actually tried to do it properly, from a systems perspective, and drop all the legacy cruft, we had the Itanium, which nobody wanted because it was not legacy code compatible. |
You forgot the screwup between bios and controller manufacturers resulting in BIOS only able to see the 1st 8gig (hence all the fun with boot partitions)
It's one thing to put hacks in to work around oversights or limitations (note: smps always need a minimum load... Finite switching time, these days with faster switches the minimum load is ~1% of full load, once more complex controllers are used, pulse dropping or variable freq can be used )
It however is a different story when ignorance is used to push an I'll thought out architecture AND even less so when the narrative is changed to justify where we are..
This is software, more to the point FOSS software ... Zero excuse not to fix this, architect it correctly. This isn't like designing the voyager spaceprobe where there is ZERO means to change hardware and limited programming space..
I really don't accept "oh hacks have always existed", especially in this instance ESPECIALLY. As systemd was peddled in fixing the issues of the previous init....
Seriously.. everyone in software needs to go through a program subject to DO178, it's disgusting what is being peddled and accepted _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Sun Jul 21, 2019 6:35 pm Post subject: Re: Gentoo seems to be chasing nu Linux design (/usr merge) |
|
|
spork_kitty wrote: | What solutions do you guys plan on using to maintain your split /usr? |
I might change the "-consolekit -pam -polkit -systemd" line in my package.use to "-consolekit -pam -polkit -systemd split-usr" if it becomes necessary somewhere down the line.
This is Gentoo, not Fedora, not Ubuntu, not Debian. We have solved these problems already and the hysteria is totally unnecessary. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54586 Location: 56N 3W
|
Posted: Sun Jul 21, 2019 7:05 pm Post subject: |
|
|
Naib,
I'll just smile :)
Its all good stuff. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
saellaven l33t
Joined: 23 Jul 2006 Posts: 655
|
Posted: Sun Jul 21, 2019 7:48 pm Post subject: |
|
|
Hu wrote: | This problem is exacerbated by two distinct major changes, both involving /usr. First, there was the "separate usr is broken" fiasco that systemd pushed (while carefully claiming they were just messengers reporting other people's brokenness), which Naib linked above. Various boot-important programs began assuming that they could access /usr during early boot, and rather than fix those assumptions, someone hit on the idea to require /usr be a directory on /, not mounted separately, or else you must use initramfs tricks to let the system pretend that /usr is not a separate mount. That happened years ago. It was disruptive and annoying, but that is mostly settled. Everyone who wants /usr to be a separate mount has adapted, whether by blacklisting the software that cannot handle it, using initramfs tricks to work around it, or giving up and moving /usr to /. |
As Neddy pointed out, SteveL developed a patch to openrc that continues to allow a separate /usr to continue working.
WilliamH intentionally ignored that patch (and he knew about it), got himself elected to the Council, then urged the Council to officially drop support for a separate /usr, which was the LEAST robust option available, but the one that wast most politically advantageous to his agenda of pushing systemd (which is why he also assumed ownership of EVERY other init system despite being a systemd proponent). To the Council's discredit, none of them did their own research and just assumed WilliamH was telling the truth as a fellow Council member and the self-appointed owner of all of the other init systems.
No tricks were needed and things were perfectly fine before SteveL's patch set, SteveL's patches simply DID make things more robust. But, we couldn't have openrc supporting features that systemd sees as NOTABUG WONTFIX because it didn't fit Poettering's very limited view of how a system should be set up. |
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Sun Jul 21, 2019 7:49 pm Post subject: |
|
|
bunder wrote: | that freedesktop article wrote: | Here's a short, very in-comprehensive list of software we are aware of that currently are not able to provide the full set of functionality when /usr is split off and not pre-mounted at boot: udev-pci-db/udev-usb-db and all rules depending on this (using the PCI/USB database in /usr/share), PulseAudio, NetworkManager, ModemManager, udisks, libatasmart, usb_modeswitch, gnome-color-manager, usbmuxd, ALSA, D-Bus, CUPS, Plymouth, LVM, hplip, multipath, Argyll, VMWare, the locale logic of most programs and a lot of other stuff. |
|
Isn't that all RedHat code? Fedora is the new Windoze!
Last edited by Tony0945 on Sun Jul 21, 2019 7:56 pm; edited 1 time in total |
|
Back to top |
|
|
Anon-E-moose Watchman
Joined: 23 May 2008 Posts: 6160 Location: Dallas area
|
Posted: Sun Jul 21, 2019 7:54 pm Post subject: |
|
|
Hu wrote: | [1] I've only begun seeing this in the last year or so. The page Naib linked claims Fedora did this many releases ago. I guess they handled it without much noise spilling out into the things I read. |
The perks of being a binary distro, the users don't typically care as long as it works.
I've convinced that RH just won't give up until they create they very own version of dll-hell by dumping everything in one kitchen sink. _________________ UM780, 6.1 zen kernel, gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Sun Jul 21, 2019 8:21 pm Post subject: |
|
|
saellaven wrote: | WilliamH intentionally ignored that patch (and he knew about it), got himself elected to the Council, then urged the Council to officially drop support for a separate /usr, which was the LEAST robust option available, but the one that wast most politically advantageous to his agenda of pushing systemd (which is why he also assumed ownership of EVERY other init system despite being a systemd proponent). |
I encourage people who don't like this to take ownership of those packages back. You already have a choice to not accept WH's vision of the future for any of those packages, but some are less well maintained than others:
Code: | ~ $ eix -Rc '^sys-(apps|process)/(cinit|daemontools|minit|openrc|runit|s6|s6-linux-init|systemd)$'
[N] sys-apps/cinit ((~)0.2.1): a fast, small and simple init with support for profiles
[I] sys-apps/openrc (0.41.2@08/03/19): OpenRC manages the services, startup and shutdown of a host
[N] sys-apps/s6 ((~)2.8.0.1(0/2.8)): skarnet.org's small and secure supervision software suite
[N] sys-apps/s6-linux-init ((~)1.0.2.0(0/1.0)): Generates an init binary for s6-based init systems
[N] sys-apps/systemd (--): System and service manager for Linux
[N] sys-process/daemontools (0.76-r7): Collection of tools for managing UNIX services
[N] sys-process/minit (0.10-r1): a small yet feature-complete init
[I] sys-process/runit (2.1.2-r10[1]@07/01/19 -> (~)2.1.2-r10[6]): A UNIX init scheme with service supervision
[1] "flussence" /var/db/repositories/flussence
[2] "lanodanOverlay" /var/db/repositories/lanodanOverlay
[3] "anarchy" layman/anarchy
[4] "argent-main" layman/argent-main
[5] "bar" layman/bar
[6] "flussence" layman/flussence
[7] "fol4" layman/fol4
[8] "JRG" layman/JRG
[9] "powerman" layman/powerman
[10] "redcore-desktop" layman/redcore-desktop
[11] "sabayon-distro" layman/sabayon-distro
[12] "srcshelton" layman/srcshelton
[13] "steev" layman/steev
[14] "systemd-love" layman/systemd-love |
|
|
Back to top |
|
|
axl Veteran
Joined: 11 Oct 2002 Posts: 1146 Location: Romania
|
Posted: Sun Jul 21, 2019 8:51 pm Post subject: |
|
|
I think the whole effort to separate "things that could be usable to bring the system up" in /bin|/sbin and "things that are just extra" in /usr/bin|/usr/sbin is just pointless.
And further more, I really dislike the new 17.1 profile. I liked having 3 entities. lib|lib32|lib64. now in lib there's mixed lib/libexec stuff|lib32 stuff and lib64 stuff. Really dislike the new 17.1 profile.
Anyway, getting back to the new usr split issue. I feel like this has been an issue for a long time. ebuilds confused about what the split means. like USE="-split-usr" emerge systemd and the dude installs init in /usr/lib/systemd/systemd. use USE="split-usr" and init installs in /lib/systemd/systemd. and again, maybe it's the beer, but i feel like each maintainer understood instructions into his own language, and for some split usr goes in usr, for some goes in /. Not ready to name names or packages, but at least systemd is confused about where the init should be. what is that about? is it my beer? I feel like if you use USE="-split-usr" it should go in /lib and with +split-usr it should go un /usr/lib.
And one more thing. why do you need a link? not sure it's still common practice, but the (or some) of the packages that had USE="split-usr" would also do links for the binaries. like if they installed binaries in /bin/ls they would also do a link to ln -s /bin/ls /usr/bin/ls. or if the binary is in /usr/bin, the other way around. ln -s /usr/bin/ls /bin/ls. what is that about? if you have the real binary in /bin, why do you need a link to it in /usr/bin? I really hope they outgrew that stuff, coz it was really silly. |
|
Back to top |
|
|
GDH-gentoo Veteran
Joined: 20 Jul 2019 Posts: 1719 Location: South America
|
Posted: Sun Jul 21, 2019 9:01 pm Post subject: |
|
|
Yes, this is the reason why people started observing stuff like this, and yes, it seems to have been done to facilitate the introduction of /usr merge to Gentoo. However, what I consider the most important question has already been asked and answered:
https://archives.gentoo.org/gentoo-dev/message/33bb10433322ce72f2ca78cbe284d825
I don't anticipate this happening soon either, and, if the decision ends up being that /usr merge is just one more option (possibly under the control of the split-usr USE flag) for those who want it, I wouldn't mind. I consider Gentoo's handling of the systemd case, the other controversial one, reasonably satisfactory so far. I will be pissed, though, if /usr merge ends up being forced with no way of opting out. But then again, I don't see this happening without a Council vote.
To clarify:
Hu wrote: | More recently[1], there has been another big disruptive change. [...] That is: move every file from bin to usr/bin, every file from sbin to usr/sbin, then replace /bin and /sbin with symlinks to the corresponding directories in /usr. [...] To further confuse things, at least for me, systemd's page about Fedora combining /bin and /usr/bin refers to that project as usr-merge. |
Yes, this is what I believe people generally refer to as "the /usr merge". I haven't looked at what split-usr does to every affected package, but I believe that in general it just influences whether the package's executables get unconditionally installed in /usr, or whether some (the 'essential' ones) or all of them get installed in the rootfs.
That said, I don't think it is entirely correct to lump together the /usr merge and systemd. While the fact that the most cited /usr merge advocacy pages are hosted in systemd's website suggests that yes, probably quite a few of the people behind systemd are also in favor of /usr merge, I'll point out that:
- systemd, the package, does support a non-merged /usr, at least for now. All it takes is building it with meson -Dsplit-usr=true -Drootprefix=/. Which, surprise surprise, is what Gentoo's systemd ebuild does when split-usr is set. Simplifying a bit, but you get the idea.
- Unless I'm seriously mistaken, Void, a runit-based GNU/Linux distribution, has a merged /usr.
I think /usr merge is better discussed as independent from, although related to, systemd. Personally, I'm against /usr merge for two reasons already mentioned.
First reason: Despite the historical reasons behind why this filesystem layout came to be, I do find useful to have a functional rootfs, even if /usr for any reason cannot be, or is not, mounted. I'm not the author, but this post to one of Devuan's mailing lists reflects my opinion on this matter.
Hu wrote: | This problem is exacerbated by two distinct major changes, both involving /usr. First, there was the "separate usr is broken" fiasco that systemd pushed (while carefully claiming they were just messengers reporting other people's brokenness), which Naib linked above. Various boot-important programs began assuming that they could access /usr during early boot, and rather than fix those assumptions, someone hit on the idea to require /usr be a directory on /, not mounted separately, or else you must use initramfs tricks to let the system pretend that /usr is not a separate mount. |
Also my opinion. The real solution to the "separate usr is broken" fiasco is "package software correctly, then".
Hu wrote: | Everyone who wants /usr to be a separate mount has adapted, whether by blacklisting the software that cannot handle it, using initramfs tricks to work around it, or giving up and moving /usr to /. |
To Gentoo's credit, and although I know it is "not officially supported", I have /usr on an LVM2 logical volume, no initramfs, and yet I have never needed to modify any package to be able to boot so far, or needed to 'wrestle' with the distribution in any other way. The only thing I remember having to do is create a /lib/rc/bin/md5sum symlink to /bin/busybox because OpenRC wants to use the md5sum program to check for a corner case during the boot sequence, and GNU Coreutils' happens to be installed in /usr/bin, so I got an annoying warning message. I could also have copied md5sum to /bin (with cp) just as easily. And yes, with current stable OpenRC. In fact, I sometimes play with alternative init systems, and boot with them to perform tests, without even bothering to mount /usr.
Second reason
spork_kitty wrote: | Merged /usr is less modular because it consolidates the system into a single dir. |
I agree that a single directory for executables is just going to exacerbate executable name collision problems. Separate /bin, /sbin, /usr/bin and /usr/sbin at least does mitigate it a bit, because each separate directory sort of acts as a separate 'namespace'. In fact, attemps to improve software packaging with the aid of a suitable filesystem layout actually seem to be going in the opposite direction: having lots of independent directories for executables, and managing what the user 'sees' via symbolic links.
spork_kitty wrote: | What solutions do you guys plan on using to maintain your split /usr? |
Several months ago I gobally set the split-usr USE flag in /etc/portage/make.conf. And at the moment, I'm just going see where things go. Like I said, I don't expect any changes soon. But if it comes to it, I suppose I'd look into copying ebuilds for 'essential' packages to a local repository and modifying the install paths to undo the /usr merge for them. By definition, 'essential' packages should be few, and modifiying install paths should be mostly passing suitable options to the build system. |
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Mon Jul 22, 2019 2:40 am Post subject: |
|
|
OK, I synced and see a lot opf packages with "split-usr" flag. Do I turn this on or off to keep the present behavior? |
|
Back to top |
|
|
fedeliallalinea Administrator
Joined: 08 Mar 2003 Posts: 31282 Location: here
|
Posted: Mon Jul 22, 2019 5:37 am Post subject: |
|
|
Tony0945 wrote: | OK, I synced and see a lot opf packages with "split-usr" flag. Do I turn this on or off to keep the present behavior? |
Gentoo until now has used a system with usr splitted, then if you want keep same same you should enable (by default is enabled) _________________ Questions are guaranteed in life; Answers aren't. |
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Mon Jul 22, 2019 2:40 pm Post subject: |
|
|
fedeliallalinea wrote: | Gentoo until now has used a system with usr splitted, then if you want keep same same you should enable (by default is enabled) | Thank you! I will add "split-user" to my make.conf USE just to make sure.
I see why these flags did not appear on one machine. It is still on 13.0 |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6067 Location: Removed by Neddy
|
Posted: Mon Jul 22, 2019 6:43 pm Post subject: |
|
|
Personally I think the packages that provide an init/unit file but also depend on files in /usr (ie the problem child packages w.r.t. split usr) should be identified...
This should be a non-issue yet somehow it is. What EXACTLY needs to be started soo early it has to come before network and nfs? What about these applications cannot be postponed OR even better split launched (a stub to get going and then a reload post nfs)
I really am struggling to see how this became an issue OR how this cannot easily be fixed. The Freedesktop/Redhat/Systemd/Pottering excuse of "oh other packages" when one of them is part of systemd source tree is a poor excuse. More to the point why is the FOSS community just accepting this?
since udev is one of hte trouble poackages (from their perspective), why not bolster eudev with a more sane rules management. Define what is critical to boot (is alsa? no so get it the fk out of the critical path) and move on _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|