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. 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. Going back to work: nice chatting with you guys. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
