From Fedora Project Wiki

Revision as of 13:08, 1 November 2011 by Harald (talk | contribs)

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)


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


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)