On 04/10/2016 08:14, Rich Freeman wrote: > On Sun, Apr 10, 2016 at 7:55 AM, Joshua Kinard <ku...@gentoo.org> wrote: >> >> Create like, a table on the Wiki or some kind of metadata property >> per-package >> that can contain a boolean or tri-state flag indicating whether it works or >> doesn't work (or kinda works) on split-usr. Or a tracker on Bugzie. >> Something. >> > > I'm sure there will be a tracker for packages that don't work on a > merged /usr. (We are already on a split /usr.) > > Honestly, I'm still not quite sure why we're even having this > discussion. I don't think anybody actually intends to make any > changes at all. If they do, they should issue some kind of plan and > indicate what they're looking for from everybody else.
Agreed. A plan is most definitely needed if we ever choose to pursue a policy of only supporting non-split-/usr installs, especially if we want to handle cases like mine where we try to make migration of existing installs possible or not. [snip] > It seems to me that we're just having a general discussion about the > pros/cons of a /usr merge. That is nice, but people are getting > worked up because they think that somehow whoever "loses" this > "discussion" will get something shoved down their throats or won't be > able to have something nice. "General discussion" -- hah! Maybe it's the way Thunderbird is displaying it, but I have five distinct, top-level threads in my gentoo-dev folder for this discussion. I think we left "general" back there after we broke through the plaid barrier. That said, I don't really think there are any pros or cons of split or merged. Largely, what's being discussed is the after-effects of what once was a common approach to filesystem layout. Myself, I only went the split-usr route because of habit, itself which started because when I set up my first Gentoo system. I studied both the then-Gentoo Security and Debian Security manuals, which indicated a split-/usr layout had certain advantages in that you could limit capabilities via mount options. Mainly, /usr didn't need devices, so "nodev" was common there. Along with /var having "noexec" and "nodev". I've pretty much stuck to that layout approach since then out of habit. Certainly, I've got a few VMs where I have just /, /boot, and /tmp as my only partitions, and there's no real noticeable difference except what's in /etc/fstab. --- I think where the problem ultimately arises is a subtle conflict between filesystem semantics and system-design philosophy against the Linux kernel's device architecture and management. It's long regarded that /bin and /sbin contain system-level binaries, and /usr/bin and /usr/sbin being for almost everything else. A.k.a., a two-level binary installation hierarchy (and the BSD's extend this with a third level under /usr/local). >From the kernel angle, you have a monolithic kernel design where device drivers run in kernel space most of the time. This worked okay with traditional, static devices that didn't change a whole lot and whose resources could be determined at boot-time, before userspace is brought up. But once the Linux ecosystem needed devices that can come online from userspace or need their resource determination to be dynamic (e.g., for hotplugging), we went to the approach that the kernel needs to get out of managing devices altogether, and thus came up with udev for device management from userspace. Since udev is supposed to run from userspace, but kinda needs to interface with the kernel a lot, the split between what's system-specific and what's not clashes with the two-level file system layout. This wasn't anything new...this conflict has existed elsewhere for a long time (namely in X11), but it came to a head when udev maintainers (and later, systemd maintainers) questioned the approach, and largely decided it wasn't worth it, and a merged filesystem, with /usr not separate, was simpler and more elegant. --- But really, does it matter where the binaries all live? It's just a design decision. Every OS had a different approach, such as NetWare running virtually everything out of SYS:SYSTEM, and Windows out of C:\WINDOWS. Heck, for the longest time, you could *not* install Windows on anything other than the first partition of the first drive, because software literally hardcoded filespec strings as "C:\WINDOWS\...". And even why C:, the third letter of the alphabet, for the first fixed disk? Because A: and B: were reserved for systems that needed two floppy drives. Yay MS-DOS! If it were possible to give every binary and file out there a unique name, you wouldn't even need directories. You could have a totally-flat namespace with all files of any kind under /, and let security models handle who sees/accesses what. But in that setup, would you even need "/"? > Almost every big change that has become popular in Gentoo just started > out as another alternative, and support grew organically. I don't > really see the need to reach some kind of consensus here. I'd love to > have an option of a /usr merge and a migration path. I'd love to see > it as the default, but that is a different discussion, and if it is > optional then it is also a less contentious discussion whichever way > it goes. I don't think there is a viable migration path that can cover all scenarios. I have one of the simpler disk layouts, with MD-RAID to merge separate physical disks into /dev/md* and then my unencrypted filesystems live there. Certainly, my /usr partition on those systems is big enough that I could cp /* into /usr, then change my root= parameter to the kernel to have it treat my /usr partition as /. That'd be the simplest method for me, but it would leave me with a ~3GB block of dead diskspace on those systems. The only real way forward for migration would literally be to back the / and /usr filesystems up (minimum), blow away the filesystem (and RAID or whatever else) layouts, redesign it, then restore. For some people, this would only take a few hours. Others, it'd be days, if not longer. Some probably wouldn't mind the time investment. Others (like me), just don't have the time (or motivation) to do such a task right now. That is really my only issue here. I guess the saving grace is UNIX filesystems in general are trivially easy to backup/restore (or migrate, etc). I migrated a Windows install once and discovered that Windows records disk serial numbers in the Registry, which it used to quickly find the disk with C:. Took me several hours to figure that out, then to build a BartPE disk that I could use to edit the specific registry hive and delete those serials. Then, unsurprisingly, Windows just shrugs and uses the new disk serials as defaults and records them in place of the old ones. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 6144R/F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
