From Fedora Project Wiki

The contingency plan is flawed

The contingency plan is flawed. Disregarding the compat symlinks is not an option as those will be needed for third party scripts, FHS compliance, user comfort, etc.

  • This is not true. The symlinks in the package from %post are still there. --harald 12:34, 1 November 2011 (UTC)
    • It was unclear to me that you're proposing that all package maintainers with programs or libraries in / will need to update their packages to carry the compat symlinks in addition to replacing the / directories. Perhaps if you add your middle two bullets from http://lists.fedoraproject.org/pipermail/devel/2011-October/158810.html to the Roadmap section it will be more clear.
  • Actually there is no contingency plan at all. Basically when we decide to start changing the packages, there is no way back apart from reverting all the changes in the huge number of packages investing almost the same amount of time that was needed to put the changes in.

A lot of work

Seems like a lot of work if you want all packages placing things in /bin, /sbin, /lib, and /lib64 to not only change their installation directory but also add code to emplace compat symlinks. I liked the plan better when I misunderstood it to only be needing to replace the "/" directories with symlinks into "/usr". Also, your list of 257 packages is incomplete. For instance, you're missing bash. Linking the script that you use to generate the list so people can fix it and find the real number of affected packages would be great.

sbin -> bin separate

I would strongly suggest considering the /sbin/ => /bin/ and /{s,}}bin => /usr/{s,}bin separately. There's different considerations for each (for instance, the consolehelper porting is only necessary for the /sbin/ => /bin/ move, not for the / to /usr/ move.)

FHS

The statement "Historically /bin, /sbin, /lib had the purpose to contain the utilities to mount /usr" is only one reason for the split. The FHS specifies other reasons: http://pathname.com/fhs/pub/fhs-2.3.html#PURPOSE2. The one that sticks out as unaddressed is "Disk errors that corrupt data on the root filesystem are a greater problem than errors on any other partition. A small root filesystem is less prone to corruption as the result of a system crash." This is both helped (the root filesystem will indeed be smaller) and hindered (but the root filesystem is essential in part because it contains the tools necessary to recover from disk errors... which would no longer be the case) by this change.

Additionally, the FHS is not only specifying these directories for purely technical reasons but also for organizational reasons. For instance, /bin contains "Essential" user command binaries. The section of FHS pointed at above would seem to indicate a definition of "Essential" that includes not only what's necessary to boot (what this feature is saying is no longer necessary) but also the commands necessary to recover, repair, or restore a system. The /bin and /sbin split is even more a separation due to organization of binaries rather than a need to do that to prevent breaking the system.

  • Many of the proposed benefits of this feature, such as "/usr can be read-only and shareable. " are already present in the current /usr. For all such benefits, the benefit is actually that more files are going to be included on /usr (or the inverse, that less will be included on /).
  • For dependencies, the Feature also needs to make sure that it works for the non-programming/library files that are stored in those directories on /. For instance, /lib/udev, /lib/systemd, /lib/terminfo.... These may all be fine but they need to be considered as dependencies that may need changing.

FPC

FPC should probably be involved as obeying the FHS is a packaging mandate (they'd want to evaluate whether any of this violates the FHS or not and whether it seems justified to make an exception if so) and also, if individual packages (like coreutils) were to implement symlinks, then how to deal with that (making symlinks for the major directories in filesystem may sidestep, that, though).

  • FPC took an informal look at this today. There's a consensus that we'd be against the /usr/bin, /usr/sbin merge. Merging /bin, /sbin, /lib, /lib64 into their /usr/ counterparts and keeping the compat symlinks will probably take some Guidelines updates but out initial view is that whether or not to go forward with that portion is up to FESCo.

anaconda and docs

anaconda and the docs team are additional dependencies as documentation and code that recommends relative partition sizes would need to be updated.

single user

One thing I'm not clear on is when the switch between the initramfs and the actual / filesystem is performed. For instance, what does the user get if they boot single user? What do they get if they boot single user and /usr is on an nfs filesystem?

Special cases with non-packages

Special cases dealt with outside of packages should always be held as a last resort if a change is deemed beneficial enough and there is no other option but to do it outside of packaging (this is for two reasons -- the anaconda team doesn't like maintaining the special cases and people who attempt to upgrade without anaconda have to be made aware of that they need to perform the special case manually). Can you think of a way not to do the / => /usr directory symlinks outside of packaging?

Test Case

The test case is more of a "how to test that we changed things" rather than "how to test we didn't break things". Probably be good to supplement it with something along the lines of "login and see that bash starts up as your shell despite having moved the binary to /usr/bin" and "run /sbin/ifconfig |/bin/grep -i ip to verify that commands used in user shell scripts continue to work despite having moved."

Consolehelper

The feature page is ambiguous - what is the proposed plan regarding usermode ("consolehelper")? If the plan is to remove it, what replaces it, and who does the work for the ~73 packages that currently depend on userhelper{,-gtk}?

/boot

What about /boot? It is not mentioned as a well defined directory. Depending on the way the initramfs is generated it may be shareable or not. --Till 19:14, 25 October 2011 (UTC)

/sbin is root/privileged users only

I strongly don't want sbin removed anywhere. It's for root/privileged users only to execute. Even if its original intent was static bin. Do not stuff that into any bin directory. This is a pure waste of time. We should be moving root/privileged user tools out of /bin and into /sbin /usr/sbin (superuser bin) where some really should belong.

Unacceptable

I think that this is totally unacceptable. Reasons are:

  1. partitioning of disk is important for a lot of use-cases and should not be ignored. / and /usr are different partitions very often.
  2. /sbin, /usr/sbin should contain binaries for super-user. E.g. fdisk is not for unprivileged user because if can easily damage system.
  3. / partition should contain minimal base system that could be read-only after boot, /usr is for user packages. Ignoring those definitions could lead to total Windows-like mess instead of elegant UNIX-like system. I wonder that someone thinks that "very known system" is more modern and elegant?
  4. Messing up all things in one directory does not make system simpler, it creates more chaos... This proposal calls strong emotions against breaking important traditions and rules.

--Alukin

no major problems nor great value

I see no major problems nor great value in this change. Several points require clarification.

  • Is the plan is to symlink the directories, not the individual files ?
  • The concept of a superuser-bin:/sbin /usr/sbin isn't meaningful anymore as users my have capabilities or SEL context to perform specific admin functions and various security profiles requires multiple distinct admin roles.
  • This project will encourage developers, ignorant of FHS, to code atrocities such as "/usr/bin/ls", creating a new form of non-portability. I suggest that /usr/bin NOT be used as the real directory, but instead an new directory created such as /usr/biNG be used with others dirs linking to this. Similar changes for /usr/libNG* may be justified. This will at least obviate the majority non-portability it encourages.

--User:stevea

without initramfs

Will this still work for systems that boot just kernel without initrd/initramfs? (NOTE: there's a major difference between "we do not support booting without initrd, it may still work however" and "we make booting without initrd impossible")

new meaning of /

I fail to understand new meaning of / filesystem. Currently / is a part of boot chain (simplified):

  1. BIOS reads first 512 bytes (MBR) of boot media and runs it. Nothing else. It does not knows what loader it boots. It even don't have to know about partitions.
  2. MBR contains the code, that reads the rest of boot loader and runs it. Nothing else. It does not know about OS, mountpoints, etc.
  3. Boot loader reads kernel (and optionally initrd) and runs it. Nothing else. The only thing that bootloader does is running the kernel.
  4. Kernel (apart from initializing hardware) mounts / filesystem and runs /sbin/init. Nothing else. It does not have to know about other mountpoints, encryptions, installed software and daemons.
  5. Init @ root fs mounts remaining filesystems, makes necessary preparations and runs daemons.

Every link in this chain has a specific purpose. And / fs is the base system, that is enough to check and mount all other parts of the system together and run it. It's stable, never changing, may be even read-only. It's however still a minimal working system, that you can log in, even if all other partitions are dead. But what's the "new meaning" of root filesystem?

pushes Fedora away

What problem are you trying to solve? -- less clutter across the filesystem

  • true. But to fix it one must finally force people to read FHS standard and think before writing software. :) Moving directories around actually increases this mess, pushes Fedora away from other linux/unix distros and pushes developers away from Fedora.

snapshots only /usr

What problem are you trying to solve? -- if you snapshot /usr before updating, you have snapshotted the OS at once.

    • No, you don't. Because you don't have /etc and /var snapshots, which are actually more important then /usr. Talking about fedora, you can recover all the lib/bin/usr files from a simple rpm -qa output. But you cannot recover /var and /etc this way.

rpm and /usr @network

Ok, so imagine you have a /usr mounted from a network location and you want to update a package. So maybe you mount the master copy of /usr on your master machine and update /usr with your package manager. [...] But what about /sbin /bin /lib and /lib64? They still have the old binaries.

  • this problem is not fixed by bin->usr move either. If you're talking about /usr @network AND about package manager controlling all the files around, then you must also move /var and /etc to /usr as well, otherwise installed software may just not start (missing init.d script) or won't work (missing configuration, missing /var/lib/ subdirectories, etc). Same with /boot + /lib/modules. So in this case to have a consistent system you'll have to export entire root fs anyway. And then moving /bin to /usr/bin is just an unnecessary attempt to break something.

separate /usr broken because of systemd?

BTW, is separate-usr-is-broken the only "broken" thing currently? And it was not "broken" before systemd? I mean, systemd is the first and only init system revealing this brokeness? Then, maybe, don't change the world, just fix systemd?

  • systemd is not broken! Read the document again. --harald 12:57, 7 November 2011 (UTC)

Updating the initramfs

In this question you argue that if someone had a separate /usr with all the binaries, the general purpose rescue binaries like fdisk and alike in /bin and /sbin would not be updated by the package management and thus wont get a glibc security update. But the same applies to the initramfs: If you propose to have the rescue binaries in the initramfs, then you need to outline a way to update the initramfs through the package management. This question is completely unclear ATM. --Cwickert 17:04, 7 November 2011 (UTC)

  • Same applies to the current initramfs as it is now... This would be a separate feature, not specifically tight to this one --harald 17:16, 7 November 2011 (UTC)
    • It may be a different problem, but is becomes more pressuring with this feature and thus should be addressed. --Cwickert 17:42, 7 November 2011 (UTC)
      • Why is it more than before? --harald 17:56, 7 November 2011 (UTC)
Retrieved from "https://fedoraproject.org/w/index.php?title=Talk:Features/UsrMove&oldid=260744"