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

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



  Wow, if this sort of bug report is re-evoking questions on the whole
relevance of the historical FHS to modern distros, it does seem that
some real "soul searching" is in order on the part of the community as
far as the future of where people see Debian/GNU/Linux headed. "Begin
with the end in mind," right? Not all roads lead to the same place, and
you choose a path according to where you want to end up.

  Throwing my own two cents in: as far as Debian itself goes, I think
this distro ('stable', in particular) has a reputation of being a solid,
stable, rock of confidence that others can build off of and deviate
from. The center should hold, so that if something goes wrong in the
branches, the problem can hopefully be localized as quickly and
conveniently as possible.
  I could be wrong, but my (admittedly stereotyped) impression of the
standard use cases is that if you've got someone who DOES want to mount
/usr separately from "/" (e.g. over NFS or because of a selectively
encrypted LVM), such person is more likely wanting to do so in "pure
Debian", rather than, say, in Ubuntu.

  In summary, I would argue that Debian's "place in the world" is such
that it should head down the path of fixing these FHS violations
strictly, rather than the path of loosening the policy. Give the
sys-admins who have been laboring with *nix for a couple decades a
Debian with single user mode in tip-top condition, always behaving "as
it should" as these foundational "old-timers" would see it. Enforce a
policy that anything being put into /sbin or /bin must pass the "ldd
test". If a dependency is in /usr/lib then negotiations have to be made
to reach an agreement to either "downgrade" the binary to /usr/{s,}bin
or "upgrade" the library to /lib. (In the case of downgrading the
binary, you can say that the user of the Debian package bears the
responsibility to have ensured that the executables he personally
considers "essential" in his own context were accessible where he would
need them when he would need them. But the distro itself should take
responsibility for being CONSISTENT, and thus should not say, "Here's
something available to you in /sbin---oh, but you can't actually use it
from there (so to speak).")
  If someone wants a distro with a (totally?, partially?) revamped,
simplified, filesystem hierarchy that will make Linux less convoluted
and even more accessible to the wide modern market, then let them go
wild in a Debian derivative. Let Debian be the solid, faithful dad they
can go back to for advice or recovery if and when they fall or need it.

-Zach

PS Sorry if my inspirational speech here is a repetition of recent
discussion on devel lists which I don't participate in. But heck,
nobody's closed my bug report yet, so now you've got my two cents thrown
in there!



Reply to: