On Mon, Sep 12, 2011 at 3:35 PM, Canek Peláez Valdés <can...@gmail.com> wrote: > On Mon, Sep 12, 2011 at 3:00 PM, Michael Mol <mike...@gmail.com> wrote: >> On Mon, Sep 12, 2011 at 2:37 PM, Canek Peláez Valdés <can...@gmail.com> >> wrote: >>> On Mon, Sep 12, 2011 at 1:39 PM, Michael Mol <mike...@gmail.com> wrote: >>>> The first step in a clean solution, IMO, is to revert that change. The >>>> second step is to fix the 'silent failure' problem for packages which >>>> depend on /usr before /usr is available. >>> >>> No fixable, in reality. The flexibility of udev is in part in that the >>> userspace can (and actually do) run arbitrary scripts and binaries >>> from udev rules. You can "fix" the ones that require binaries in /usr >>> *NOW*, but not forever, unless you forbid the use of arbitrary >>> binaries from udev rules. >>> >>> And then you lose the flexibility. >> >> Here's the chief problem with that argument...it's not just limited to >> /usr. If you're going to say that a script can do whatever it wants, >> and udev will make declarative statements about supported and >> unsupported filesystem layouts to allow that to work, then you *must* >> say that the entire filesystem be on the same partition as /, or that >> one must use initramfs. >> >> Because you can't know that a script won't depend on something under >> /var. Or /opt. Or /home. And if if /home is excluded from this >> must-be-available set, what makes it more special than /usr? If it's >> OK to say "no script must access files under /home", then why isn't it >> OK to say "no script must access files under /usr"? >> >> You're imposing a rule either way. If a script author must be aware of >> rules, why can't he be aware of something like "be aware of when a >> file may or may not be available, and do not access files which are >> not yet available. If you can't know, document the requirement so that >> a package maintainer or sysadmin can ensure your constraints are met." >> That seems pretty simple to me. It's the *job* of package maintainers >> to understand how software interacts with a distro's infrastructure. >> >>> >>> The explanation from >>> http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken >>> seems more than reasonable to me: /lib and /bin and /sbin were the way >>> old-Unix solved the problem of needing some binaries before /usr was >>> mounted. >> >> I read that page. I understand the problem. I'm not convinced. > > I can respect that. I can only then say that we must agree to > disagree, because I also understand the problem, and I am convinced. > > But what you guys don't seem to realize is that /lib and /bin and > /sbin was the original hack: everything really should go into /usr, > because now (with an initramfs) we can do what we were not able 30 > years ago. We not need anything in /, really.
Then is / anything other than a root node in a logical tree? > Anyway, I'm not trying to convince anyone. Just wanted to show the > links and to make clear among other things that *no one* has ever > proposed (even less try to force) a non separatable /var. You can > speculate all you want, but that's all: speculation. Everything seems to revolve around coming upon a more-correct or most-correct solution. The speculation is nothing more than thinking ahead about consequences, and whether or not the change to udev ultimately solves anything, or whether it is merely change for change's sake. I don't see that it solves the logical problem the Fedora dev claims it solves. -- :wq
