Talk:Features/UsrMove

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.

• 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.

• 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.)

• 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 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 the docs team are additional dependencies as documentation and code that recommends relative partition sizes would need to be updated.
• 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 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?
• 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}?

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)

Feature page needs to have details in How to Test, Documentation, and Release notes before it can go to FESCo for approval. Thanks! --Rbergero 08:40, 27 October 2011 (UTC)