[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#652011: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib

On Wed, Dec 14, 2011 at 03:31:41PM -0600, Jonathan Nieder wrote:
> Two clarifications:
> Jonathan Nieder wrote:
> > Roger Leigh wrote:
> >> The question that needs answering is this:
> >>
> >>   "what are the reasons, today, for a separate /usr?"
> >
> > No, I don't think an answer to that precise question today would be
> > especially helpful.
> I'd like to apologize for this response.  Hearing use cases is always
> welcome, especially when they are given in the spirit of being helpful
> rather than defensiveness.

No worries, sorry if my initial response was also rather aggressive.
I would simply like to have some critical thought put into considering
/why/ we have things the way they are, rather than having "historical
reasons" as a rather unsatisfying answer, especially when those reasons
may no longer be applicable.

> > As far as I can tell, it is not especially
> > unsensible to use separate partitions for /usr, /etc, /var, /boot, and
> > /opt.
> It occured to me too late that it might sound like I am saying a /etc
> partition separate from / can work.  By "separate" I only meant
> "distinct" (i.e., the /usr, /etc, /var, etc inodes all coming from
> different mounts).
> I also think I misunderstood your message.  What kind of unification
> are you advocating?  Fedora's setup, for example, allows /usr to be a
> separate filesystem.

I'm not currently really advocating for any specific unification now.
While I think in the long run it would make sense to merge the
content of / and /usr, I don't think wheezy is the right time for it.
We might want to do some groundwork though, such as not having
duplicate paths on / and /usr.

There are two different questions here:
- do we want do permit /usr as a separately-mountable filesystem?
- do we want /usr at all?

The udev concerns the first; though being able to mount /usr in
the initramfs would ameliorate that.  Long-term though, we might
want to do away with it entirely and leave it as a compatibility
symlink (for new installs).


  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Reply to: