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

Package: general; Maintainer for general is debian-devel@lists.debian.org;

Reported by: Zachary Harris <zacharyharris@hotmail.com>

Date: Wed, 14 Dec 2011 04:42:02 UTC

Severity: wishlist

Done: Russ Allbery <rra@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Wed, 14 Dec 2011 04:42:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Zachary Harris <zacharyharris@hotmail.com>:
New Bug report received and forwarded. Copy sent to debian-devel@lists.debian.org. (Wed, 14 Dec 2011 04:42:05 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Zachary Harris <zacharyharris@hotmail.com>
To: submit@bugs.debian.org
Subject: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Tue, 13 Dec 2011 23:39:31 -0500
Package: general
Severity: serious
Justification: Policy 10.1.1

My understanding of the FHS would be that if a library is a dependency of a
binary in /bin or /sbin, then such library belongs in /lib, not
/usr/lib. (If
for some reason the library is also desired in /usr/lib then a sym link from
/lib to /usr/lib, but not the other way around, is acceptable.) A review of
past bug reports (e.g. #633019 and #639939 from this summer) shows that this
policy gets repeatedly violated in Debian until someone catches it.

Here is a test to reveal the current culprits on my own Squeeze
installation:
> ldd /{s,}bin/* | /bin/grep usr | cut -f1 -d"(" | sort -u
        libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8
        libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2
        libdiscover.so.2 => /usr/lib/libdiscover.so.2
        libexpat.so.1 => /usr/lib/libexpat.so.1
        libfuse.so.2 => /usr/lib/libfuse.so.2
        libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0
        libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0
        libhal.so.1 => /usr/lib/libhal.so.1
        libhal-storage.so.1 => /usr/lib/libhal-storage.so.1
        libnfnetlink.so.0 => /usr/lib/libnfnetlink.so.0
        libnl.so.1 => /usr/lib/libnl.so.1
        libntfs-3g.so.75 => /usr/lib/libntfs-3g.so.75
        libntfs.so.10 => /usr/lib/libntfs.so.10
        libpcsclite.so.1 => /usr/lib/libpcsclite.so.1
        libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8
        libz.so.1 => /usr/lib/libz.so.1

Here is one objective test of conformity to this aspect of the FHS
requirements. The command "ldd /{s,}bin/* | /bin/grep usr" (or something
equivalent) should return nothing. (Well, OK, there could be weird
exceptions
where the string "usr" appeared in the name of an essential binary or
library,
but you get my point.)

-Zach



-- System Information:
Debian Release: 6.0.3
  APT prefers stable
  APT policy: (700, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.39-bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash





Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Wed, 14 Dec 2011 05:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Wed, 14 Dec 2011 05:03:03 GMT) Full text and rfc822 format available.

Message #10 received at 652011@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: debian-devel@lists.debian.org
Cc: 652011@bugs.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Tue, 13 Dec 2011 21:00:04 -0800
Zachary Harris <zacharyharris@hotmail.com> writes:

> My understanding of the FHS would be that if a library is a dependency
> of a binary in /bin or /sbin, then such library belongs in /lib, not
> /usr/lib. (If for some reason the library is also desired in /usr/lib
> then a sym link from /lib to /usr/lib, but not the other way around, is
> acceptable.) A review of past bug reports (e.g. #633019 and #639939 from
> this summer) shows that this policy gets repeatedly violated in Debian
> until someone catches it.

I'm increasingly convinced by the recent discussion on debian-devel that
doing all the (rather substantial) work required to keep this separation
working is a waste of our collective time.  We're not doing a very good
job at it anyway, chasing all the library dependencies is a fair amount of
work, and things have to keep moving around as dependencies change.  And
this is all to support use cases that, while real, are fairly marginal in
my estimation.  This does not seem like the most effective place for us to
be spending our time.

I don't know if it's worth the effort to unify /bin and /usr/bin or the
other similar things that have been discussed from time to time, but I do
think it may be time for Debian to just officially say that we don't
support /usr on a (meaningfully) separate partition from /bin and /lib,
and that binaries in /bin may have dependencies on /usr/lib.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Wed, 14 Dec 2011 12:04:24 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ian Jackson <ijackson@chiark.greenend.org.uk>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Wed, 14 Dec 2011 12:04:50 GMT) Full text and rfc822 format available.

Message #15 received at 652011@bugs.debian.org (full text, mbox):

From: Ian Jackson <ijackson@chiark.greenend.org.uk>
To: Russ Allbery <rra@debian.org>
Cc: debian-devel@lists.debian.org, 652011@bugs.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Wed, 14 Dec 2011 12:00:51 +0000
Russ Allbery writes ("Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib"):
> I don't know if it's worth the effort to unify /bin and /usr/bin or the
> other similar things that have been discussed from time to time,

The situation we have, where this is something we vaguely try to do
but don't spend a lot of effort on, is IMO perfectly reasonable.

For example, it would be possible for someone who wanted to make a
Debian derivative which shipped with a separate /usr by default to go
and fix all of these bugs, and we shouldn't make that impossible by
deliberately conflating / and /usr or by rejecting the bug reports.

> but I do think it may be time for Debian to just officially say that
> we don't support /usr on a (meaningfully) separate partition from
> /bin and /lib, and that binaries in /bin may have dependencies on
> /usr/lib.

If we want to relax the policy, we could say "in principle we think
this is a nice to have but whether to support it is up to maintainers
of individual packages".

Let's please not go straight to deliberately breaking it for the sake
of tidiness.

Ian.




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Wed, 14 Dec 2011 17:57:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Zachary Harris <zacharyharris@hotmail.com>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Wed, 14 Dec 2011 17:57:06 GMT) Full text and rfc822 format available.

Message #20 received at 652011@bugs.debian.org (full text, mbox):

From: Zachary Harris <zacharyharris@hotmail.com>
To: 652011@bugs.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Wed, 14 Dec 2011 12:53:24 -0500
  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!




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Wed, 14 Dec 2011 20:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Wed, 14 Dec 2011 20:45:03 GMT) Full text and rfc822 format available.

Message #25 received at 652011@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Zachary Harris <zacharyharris@hotmail.com>, 652011@bugs.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Wed, 14 Dec 2011 20:43:04 +0000
On Wed, Dec 14, 2011 at 12:53:24PM -0500, Zachary Harris wrote:
>   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.

At the same time, this does not mean that Debian should never change.
Do you have any concrete answers to the questions posed?

Merging / and /usr (in either direction) would always result in a
system with compatibility links.  It's not like anything would be
broken by the change--all the paths available now would continue to
be available.

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

This is a bit beside the point.  People keep bringing up mounting /usr
over NFS.  No one to date has provided a sensible use case for it.
This is because "old timers" (or whoever) have failed to notice a
fundamental flaw: *package management does not work with a shared /usr*.

On a Debian there are really only two categories for partitions:
those under the control of the package manager, and those which
are not (user data etc.).  Does it make sense to split package-managed
files over multiple partitions? (other than /var)

This is *the* key point.  Under a package managed distribution /
and /usr are part of a *managed whole*.  They can't exist separately,
even if they are on different partitions, mounted over NFS, or
whatever.  It's fine that such things /work/, but we do need to
question /why/ one would do such a thing.  If you're mounting /usr
over NFS, the real question is "why aren't you mounting / over NFS,
which also then includes /usr?".  Mounting /usr separately makes no
sense *at all*.

The same argument applies to encryption.  / and /usr both contain a
selection of programs, libraries etc.  If you're encrypting one, why
would you not encrypt all of it?  And the same for mounting read-only.

The question that needs answering is this:

  "what are the reasons, today, for a separate /usr?"

Excluding "historical practice".  What real function does it have?
Does it have any reason to continue to exist?

And regarding the LSB: I checked, and it would be entirely compliant
for Debian to merge the two.

> 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).")

The problem here is, can we /be/ consistent?  What is one system's
essential package required for bringing up a working system is
someone else's occasionally-used tool that's not important at all.
Yet both might be required to be on the rootfs.  We can't be all
things to all people in the current state.  But unification /would/
*guarantee* things would always work and be consistent: every
program and library would always be right there on the rootfs.

The status quo is a "best effort".  Things sometimes break, and
there's an continuing migration of "essential" packages to the
rootfs.  Given that a modern initramfs can mount pretty much any
filesystem, either locally or over a network, what's the *real*
reason for a separate /usr?  It's certainly not for any booting-
related reason.


Regards,
Roger

-- 
  .''`.  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.




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Wed, 14 Dec 2011 21:16:23 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Wed, 14 Dec 2011 21:16:23 GMT) Full text and rfc822 format available.

Message #30 received at 652011@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: 652011@bugs.debian.org
Cc: Zachary Harris <zacharyharris@hotmail.com>
Subject: Re: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Wed, 14 Dec 2011 15:14:19 -0600
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.  As far as I can tell, it is not especially
unsensible to use separate partitions for /usr, /etc, /var, /boot, and
/opt.  And whether it is sensible or not, unless you have a tool in
mind that will automatically change the partitioning scheme of a
running system, that's not going to help udev or crda very much.

An obvious question to answer to help these programs is whether it
makes sense to make /usr a separate partition and not mount it before
starting init.  An even more obvious question is "where is the patch
for initramfs-tools?". ;-)

[...]
> The same argument applies to encryption.  / and /usr both contain a
> selection of programs, libraries etc.  If you're encrypting one, why
> would you not encrypt all of it?  And the same for mounting read-only.

Regarding mounting read-only: files in /etc change far more often than
files in /usr/bin, for one thing.

Hope that helps,
Jonathan




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Wed, 14 Dec 2011 21:33:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Wed, 14 Dec 2011 21:33:10 GMT) Full text and rfc822 format available.

Message #35 received at 652011@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: 652011@bugs.debian.org
Cc: Zachary Harris <zacharyharris@hotmail.com>
Subject: Re: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Wed, 14 Dec 2011 15:31:41 -0600
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.

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

Sorry for the noise,
Jonathan




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Wed, 14 Dec 2011 22:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to "J.A. Bezemer" <j.a.bezemer@opensourcepartners.nl>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Wed, 14 Dec 2011 22:09:04 GMT) Full text and rfc822 format available.

Message #40 received at 652011@bugs.debian.org (full text, mbox):

From: "J.A. Bezemer" <j.a.bezemer@opensourcepartners.nl>
To: 652011@bugs.debian.org
Cc: debian-devel@lists.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Wed, 14 Dec 2011 22:43:38 +0100 (CET)
On Wed, 14 Dec 2011, Roger Leigh wrote:

[..]
> The same argument applies to encryption.  / and /usr both contain a
> selection of programs, libraries etc.  If you're encrypting one, why
> would you not encrypt all of it?

Speed.

On one of my relatively low-power portable systems, I have everything 
encrypted except /boot and /usr. /boot for obvious reasons; /usr because 
decryption is heavily CPU-bound, making encrypted /usr unworkably slow. 
Since encryption is for privacy reasons, I need encrypted / because of 
/etc. (And encrypted /home and /var of course.)

Indeed, this means that programs in /bin and libs in /lib are also 
encrypted. But this actually does _not_ slow things down: the Linux disk 
cache is sensibly caching the decrypted data, so often-used stuff from 
/bin and /lib happily remains in already-decrypted cache. The interesting 
stuff from /usr is generally too large and too seldomly used to remain 
cached.

So I'd say "preferably not" move /bin and /lib to /usr; but I'd say 
"absolutely definitely not" move /usr/bin and /usr/lib to /.

(Well, in the latter case: unless you make sure that /bin and /lib are 
actually mountable separately. But that would really defeat the purpose.)


Best regards,

Anne Bezemer




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Wed, 14 Dec 2011 22:51:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Wed, 14 Dec 2011 22:51:07 GMT) Full text and rfc822 format available.

Message #45 received at 652011@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: "J.A. Bezemer" <j.a.bezemer@opensourcepartners.nl>, 652011@bugs.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Wed, 14 Dec 2011 23:47:00 +0100
[Message part 1 (text/plain, inline)]
On 14.12.2011 22:43, J.A. Bezemer wrote:

> So I'd say "preferably not" move /bin and /lib to /usr; but I'd say 
> "absolutely definitely not" move /usr/bin and /usr/lib to /.
> 
> (Well, in the latter case: unless you make sure that /bin and /lib are 
> actually mountable separately. But that would really defeat the purpose.)

Moving the bits from /lib and /(s)bin to /usr doesn't mean you won't be
able to have /usr on a separate partition.
It just means you'd have to use something like initramfs-tools to mount
/usr for you.

Actually, by moving the bits to /usr, you'd have to encrypt even less.


Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Wed, 14 Dec 2011 23:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Wed, 14 Dec 2011 23:09:04 GMT) Full text and rfc822 format available.

Message #50 received at 652011@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: 652011@bugs.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Thu, 15 Dec 2011 00:08:02 +0100
[Message part 1 (text/plain, inline)]
On 14.12.2011 06:00, Russ Allbery wrote:

> I'm increasingly convinced by the recent discussion on debian-devel that
> doing all the (rather substantial) work required to keep this separation
> working is a waste of our collective time.  We're not doing a very good
> job at it anyway, chasing all the library dependencies is a fair amount of
> work, and things have to keep moving around as dependencies change.  And
> this is all to support use cases that, while real, are fairly marginal in
> my estimation.  This does not seem like the most effective place for us to
> be spending our time.

nod.

I had to move a couple of libraries myself in the past and it's a
laborious task (and I've often seen it not done right).
E.g. while moving the library file to /lib, you should keep the devel
files (.so symlink, .a/.la files, pkg-config files) in /usr/lib.
You can't just move the .so symlink around, so you need to do it manually.

The problem is, that the major build systems (autoconf/automake, cmake)
don't have support for such split installations.

> 
> I don't know if it's worth the effort to unify /bin and /usr/bin or the
> other similar things that have been discussed from time to time, but I do
> think it may be time for Debian to just officially say that we don't
> support /usr on a (meaningfully) separate partition from /bin and /lib,
> and that binaries in /bin may have dependencies on /usr/lib.
> 

The more I think about it, the more I like the idea to simply move
everything to /usr, and make /(s)bin and /lib symlinks.

While I personally never found it very useful to put /usr on a separate
partition, I acknowledge that such installations are around (especially
since d-i presents this partitioning scheme in such a prominent way) and
we must not break such installations on upgrades. We'd have to make
sure, that for such installations e.g. a initramfs is installed, which
can mount /usr.

That said, I'd also like to see us deprecate a separate /usr altogether.
And a first step would be to update d-i to no longer present this option.

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Thu, 15 Dec 2011 00:45:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Zachary Harris <zacharyharris@hotmail.com>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Thu, 15 Dec 2011 00:45:05 GMT) Full text and rfc822 format available.

Message #55 received at 652011@bugs.debian.org (full text, mbox):

From: Zachary Harris <zacharyharris@hotmail.com>
To: 652011@bugs.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Wed, 14 Dec 2011 19:42:17 -0500
[Message part 1 (text/plain, inline)]
On 12/14/2011 04:43 PM, J.A. Bezemer wrote:
>
> On Wed, 14 Dec 2011, Roger Leigh wrote:
>
> [..]
>> The same argument applies to encryption.  / and /usr both contain a
>> selection of programs, libraries etc.  If you're encrypting one, why
>> would you not encrypt all of it?
>
> Speed.
>
> On one of my relatively low-power portable systems, I have everything
> encrypted except /boot and /usr. /boot for obvious reasons; /usr
> because decryption is heavily CPU-bound, making encrypted /usr
> unworkably slow. Since encryption is for privacy reasons, I need
> encrypted / because of /etc. (And encrypted /home and /var of course.)
>
> Indeed, this means that programs in /bin and libs in /lib are also
> encrypted. But this actually does _not_ slow things down: the Linux
> disk cache is sensibly caching the decrypted data, so often-used stuff
> from /bin and /lib happily remains in already-decrypted cache. The
> interesting stuff from /usr is generally too large and too seldomly
> used to remain cached.

  Yep, that's actually the case for how I got pulled into the fray here.
I recently did a squeeze install on the new laptop. I take the laptop
out on the world a lot in a powered off state, and thought it would be
nice to try Luks encryption for an extra layer of security, mostly for
the sake of /home, /var /etc and swap. So I chose the automated
partitioning scheme for encrypted LVM on the install disc. I really just
wanted the encryption, and at first thought the extra LVM layer was an
annoyance. Later, I found the LVM layer was cool to have because /
needed much more space than d-i gave it, for backports kernels and
headers (for modules for wireless card, etc.), and encrypted /usr
(especially without AES acceleration on my processor) was a noticeable
performance loss. So I was able to move /usr to the unencrypted
partition I made after resizing LVM, expanded /, got backports kernels
going (to the joy of the now working sound-card on the new machine), and
now everything is working great. ...
  ... With the one caveat which brings us to today, that now I get
complaints in the boot log when certain /bin functions are called with
dependencies in /usr/lib that haven't been mounted yet. OK, so I admit
it, don't shoot me, but the truth of the matter is that these boot log
errors haven't yet practically caused me harm in any way (other than the
time spent trying to be a responsible admin for my system and track down
the reason I'm seeing log errors before they DO jump out and bite me
right at the time of a crucial work deadline or whatever).

On 12/14/2011 06:08 PM, Michael Biebl wrote:
> I acknowledge that such installations are around (especially
> since d-i presents this partitioning scheme in such a prominent way)

   Yep! In fact, one irony in this discussion is that on my own I
wouldn't have dreamed of going to the effort to take the initiative to
understand working with a separate /usr partition, if not for the fact
that d-i had put it out in front of me! But actually, at the end of the
day, it worked out well because I (and apparently others) have found
that having a generally encrypted system with an unencrypted /usr is
actually advantageous. And if someone does snag my laptop and want to
yank out the hard drive, I'm really not concerned about them being able
to find out what applications I have in my /usr.


On 12/14/2011 03:43 PM, Roger Leigh wrote:
>
>>  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).")
> The problem here is, can we /be/ consistent?  What is one system's
> essential package required for bringing up a working system is
> someone else's occasionally-used tool that's not important at all.
> Yet both might be required to be on the rootfs.  We can't be all
> things to all people in the current state.

  I think we're not fully understanding each other here. You are talking
about "one system's essential package" vs. another system's
"non-important tool". We can agree that the package priority level
(important vs. standard vs. optional) is subjective, and we can agree
that in many ways, in many cases, it may be a subjective call as to
whether an executable belongs in /sbin vs. /usr/sbin, for example. But
what I'm calling "consistency" is as follows: once you have determined
the location of all the binary executables across a given repository,
you then have a fixed, objective, algorithmic rule for determining the
placement of all the _libraries_ in that repository. Here is the
explicit algorithm (I don't necessarily expect anyone to actually do it
this way, but I'm a mathematician and we mathematicians like to write
stuff like this out to either prove the existence of well-defined
algorithms, or conversely to expose underlying false assumptions, so
let's give it a try):

Library Placement Algorithm (LPA):

    1) Consider the set of all possible binary executables that any
    package in the given repo has chosen to put in /sbin or /bin, and
    put all such binaries there. (I realize this may not(?) be possible
    to do with a package manager, namely dpkg/apt, because of the
    existence of conflicting packages, but rememeber I'm making a point
    here with an abstract algorithmic presentation. Let's say you
    manually unpack all packages and put the binary executables there in
    /(s)bin.)
    2) Likewise, consider the set of all libs from all packages in the
    given repo and place them all in /usr/lib.
    3) Run

        > ldd /{s,}bin/* | unique

    4) Put all the libraries that appear in the output of step 3 in
    /lib. All other libs can stay behind in /usr/lib (it must be that
    they are only ever used by something in /usr).

Definition: We say a system satisfies the "FHS-LDD property" if the command

    ldd /{s,}bin | grep "=> /usr"

returns nothing.

Definition: We say a repo (or distro?) satisfies the "FHS-LDD property"
if _any system_ that installs a subset of the packages from that
repo/distro satisfies the FHS-LDD on that system.

My claim: A distro that uses the LPA satisfies the FHS-LDD property in
the most efficient manner possible. That is to say, it satisfies the
FHS-LDD property for that distro, and any other partitioning of
libraries between /usr/lib and /lib which would satisfy the FHS-LDD
property for this system would necessary place a set of libraries in
/lib which was a superset of that produced by LPA.

  If my claim is valid, then I will have shown that there is in fact a
unique, objectively "best" way for libraries to be partitioned between
/usr/lib and /lib. Now, I know from professional work experience that
this is the point where the more practically grounded folks jump in and
kick my abstract mathematician legs out from underneath me and say,
"Nice theorem buddy, but in the real world...." OK. So now to the wise
folks who said, "We all have better things to be doing than this," good
on you! Kudos to anyone who ignores my bug report in favor of doing
something with their life that actually matters!

-Zach

[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Thu, 15 Dec 2011 12:42:57 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Thu, 15 Dec 2011 12:43:00 GMT) Full text and rfc822 format available.

Message #60 received at 652011@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Jonathan Nieder <jrnieder@gmail.com>, 652011@bugs.debian.org
Cc: Zachary Harris <zacharyharris@hotmail.com>
Subject: Re: Bug#652011: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Thu, 15 Dec 2011 12:41:48 +0000
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).


Regards,
Roger

-- 
  .''`.  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.




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Thu, 15 Dec 2011 12:51:13 GMT) Full text and rfc822 format available.

Message #63 received at 652011@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: debian-devel@lists.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Thu, 15 Dec 2011 12:46:40 +0000
On Wed, Dec 14, 2011 at 10:43:38PM +0100, J.A. Bezemer wrote:
> 
> On Wed, 14 Dec 2011, Roger Leigh wrote:
> 
> [..]
> >The same argument applies to encryption.  / and /usr both contain a
> >selection of programs, libraries etc.  If you're encrypting one, why
> >would you not encrypt all of it?
> 
> Speed.
[...]
> encrypted. But this actually does _not_ slow things down: the Linux
> disk cache is sensibly caching the decrypted data, so often-used
> stuff from /bin and /lib happily remains in already-decrypted cache.
> The interesting stuff from /usr is generally too large and too
> seldomly used to remain cached.

This was brought up last time this came up on -devel.  And I think
it kind of misses the point.

You are encrypting / and not encrypting /usr.  That's fine.  But
it's a workaround.  It's not addressing the *real* goal, which is
to encrypt /etc.

That is to say, /usr is a split of /convenience/.  The real solution
would be to have /etc as a separately-mounted encrypted filesystem.
So really, keeping /usr separate is a different issue, IMHO.  This
isn't a reason to keep the /usr split, it's a reason to support
mounting an encrypted /etc in the initramfs.  Such a solution would
also satisfy those that want a read-only root but writable /etc for
admin convenience.


Regards,
Roger

-- 
  .''`.  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.


-- 
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20111215124640.GG17458@codelibre.net





Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Thu, 15 Dec 2011 13:00:22 GMT) Full text and rfc822 format available.

Acknowledgement sent to md@Linux.IT (Marco d'Itri):
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Thu, 15 Dec 2011 13:00:31 GMT) Full text and rfc822 format available.

Message #68 received at 652011@bugs.debian.org (full text, mbox):

From: md@Linux.IT (Marco d'Itri)
To: debian-devel@lists.debian.org
Cc: 652011@bugs.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Thu, 15 Dec 2011 13:57:20 +0100
[Message part 1 (text/plain, inline)]
On Dec 15, Roger Leigh <rleigh@codelibre.net> wrote:

> That is to say, /usr is a split of /convenience/.  The real solution
> would be to have /etc as a separately-mounted encrypted filesystem.
> So really, keeping /usr separate is a different issue, IMHO.  This
> isn't a reason to keep the /usr split, it's a reason to support
> mounting an encrypted /etc in the initramfs.  Such a solution would
> also satisfy those that want a read-only root but writable /etc for
> admin convenience.
You keep repeating arguments in favour of moving /{bin,sbin,lib}/ to
/usr/ :-)

-- 
ciao,
Marco
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Thu, 15 Dec 2011 13:33:14 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Thu, 15 Dec 2011 13:33:15 GMT) Full text and rfc822 format available.

Message #73 received at 652011@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: debian-devel@lists.debian.org
Cc: 652011@bugs.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Thu, 15 Dec 2011 13:29:18 +0000
On Thu, Dec 15, 2011 at 01:57:20PM +0100, Marco d'Itri wrote:
> On Dec 15, Roger Leigh <rleigh@codelibre.net> wrote:
> 
> > That is to say, /usr is a split of /convenience/.  The real solution
> > would be to have /etc as a separately-mounted encrypted filesystem.
> > So really, keeping /usr separate is a different issue, IMHO.  This
> > isn't a reason to keep the /usr split, it's a reason to support
> > mounting an encrypted /etc in the initramfs.  Such a solution would
> > also satisfy those that want a read-only root but writable /etc for
> > admin convenience.
> You keep repeating arguments in favour of moving /{bin,sbin,lib}/ to
> /usr/ :-)

Well, I think I still need persuading that this is the right direction
to move the files.  I still think that moving /usr to / is a better
strategy, albeit introducing some problems with users who would need
to resize the rootfs (but this has always been an issue with upgrades,
it's really the admin's responsibility to deal with partition sizing
prior to upgrading).

WRT mounting additional filesystems in the initramfs, how difficult
would it be to add an additional mount option to /etc/fstab entries,
e.g. "init" or "initramfs" to mark them as being required for mounting
in the initramfs.  This could include /, /usr, /etc and anything else
the admin deems necessary for booting, and would just be checked and
added when creating/updating the initramfs.


Regards,
Roger

-- 
  .''`.  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.




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Thu, 15 Dec 2011 13:39:12 GMT) Full text and rfc822 format available.

Acknowledgement sent to Zachary Harris <zacharyharris@hotmail.com>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Thu, 15 Dec 2011 13:39:13 GMT) Full text and rfc822 format available.

Message #78 received at 652011@bugs.debian.org (full text, mbox):

From: Zachary Harris <zacharyharris@hotmail.com>
To: 652011@bugs.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Thu, 15 Dec 2011 08:35:35 -0500
[Message part 1 (text/plain, inline)]
  Ok, ok, ok, I think I may have got it. Some of your comments helped
get me on the proper track of distro-oriented thinking where different
systems are picking and choosing a different subset of available
packages, but those packages have predefined locations where they have
to put things. It has rightly been pointed out to me by others here that
what is really needed is for libraries to be placed where they are
needed according to the a posteriori knowledge of the selection of
programs in /{s,}bin _on the local system_.

  So, I realized, how about a _package_ (I propose the name fhslib) that
effectively does something like this:

    1) Check ldd /{s,}bin/* for dependencies in /usr, and put copies of
    of the those libraries in /lib.
    2) Keep track (somewhere in /var) of what fhslib has put in /lib.
    3) When other packages are installed or removed, fhslib gets
    triggered to update.

  Then we continue on as currently, with library package maintainers
doing their best to be reasonable in where they think a library
generally properly belongs, so that on any given system fhslib will
hopefully only duplicate a small handful of libraries to pick up the slack.
  On my box fhslib would result in a reasonable redundancy of 4M:

    $ ldd /{s,}bin/* | /bin/grep usr | cut -f2 -d">" | cut -f1 -d"(" |
    sort -u | xargs du -Lhc ; sudo du -sh /lib ; du -sh /usr/lib
    1.7M    /usr/lib/libcrypto.so.0.9.8
    148K    /usr/lib/libdbus-glib-1.so.2
    60K    /usr/lib/libdiscover.so.2
    168K    /usr/lib/libexpat.so.1
    220K    /usr/lib/libfuse.so.2
    288K    /usr/lib/libgobject-2.0.so.0
    20K    /usr/lib/libgthread-2.0.so.0
    68K    /usr/lib/libhal.so.1
    44K    /usr/lib/libhal-storage.so.1
    28K    /usr/lib/libnfnetlink.so.0
    328K    /usr/lib/libnl.so.1
    352K    /usr/lib/libntfs-3g.so.75
    160K    /usr/lib/libntfs.so.10
    44K    /usr/lib/libpcsclite.so.1
    348K    /usr/lib/libssl.so.0.9.8
    96K    /usr/lib/libz.so.1
    4.0M    total

    370M    /lib
    2.1G    /usr/lib

Not being a package developer (yet!?), I am naive as to how much work it
would take to put fhslib together. Unless someone else really wants to
jump on it, I'd be willing to take this as an opportunity to learn a
little Debian package management and give back to the community that has
given me so much ("free beer").

-Zach

PS I think I would like fhslib to have a priority of "important" so that
someone who installs even a basic Debian system can expect FHS
compliancy. Indeed, in some sense it may be the most "minimal" systems
where it is most important.
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Thu, 15 Dec 2011 17:21:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Riku Voipio <riku.voipio@iki.fi>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Thu, 15 Dec 2011 17:21:07 GMT) Full text and rfc822 format available.

Message #83 received at 652011@bugs.debian.org (full text, mbox):

From: Riku Voipio <riku.voipio@iki.fi>
To: Roger Leigh <rleigh@codelibre.net>
Cc: debian-devel@lists.debian.org, 652011@bugs.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Thu, 15 Dec 2011 19:17:53 +0200
On Thu, Dec 15, 2011 at 01:29:18PM +0000, Roger Leigh wrote:
> Well, I think I still need persuading that this is the right direction
> to move the files.  I still think that moving /usr to / is a better
> strategy

I think we would need a very, very good reason to migrate away from /usr.
Fedora already is going the other way (/lib,bin to /usr). Going the other
way would increase fragmentation in Linux and make essentially FHS history.

Moving everything to /usr is also less work, no need to get rid of the
--prefix=/usr in most packages in debian...

Riku




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Thu, 15 Dec 2011 17:24:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to md@Linux.IT (Marco d'Itri):
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Thu, 15 Dec 2011 17:24:03 GMT) Full text and rfc822 format available.

Message #88 received at 652011@bugs.debian.org (full text, mbox):

From: md@Linux.IT (Marco d'Itri)
To: Roger Leigh <rleigh@codelibre.net>
Cc: debian-devel@lists.debian.org, 652011@bugs.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Thu, 15 Dec 2011 18:19:54 +0100
[Message part 1 (text/plain, inline)]
On Dec 15, Roger Leigh <rleigh@codelibre.net> wrote:

> > You keep repeating arguments in favour of moving /{bin,sbin,lib}/ to
> > /usr/ :-)
> Well, I think I still need persuading that this is the right direction
> to move the files.  I still think that moving /usr to / is a better
> strategy, albeit introducing some problems with users who would need
/usr to / does not allow any new features, while / to /usr allows
implementing new features like creating OS snapshots at file system
level (something which Fedora already supports) or a real complete OS
image (to be NFS-shared, replicated, etc).

> WRT mounting additional filesystems in the initramfs, how difficult
> would it be to add an additional mount option to /etc/fstab entries,
> e.g. "init" or "initramfs" to mark them as being required for mounting
> in the initramfs.  This could include /, /usr, /etc and anything else
> the admin deems necessary for booting, and would just be checked and
> added when creating/updating the initramfs.
/ is already mountable, while /etc obviously could not be if you want to
look at fstab. I see no compelling reasons to create standalone file
systems for the other directories, which are small and static.

-- 
ciao,
Marco
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Thu, 15 Dec 2011 17:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Thu, 15 Dec 2011 17:27:03 GMT) Full text and rfc822 format available.

Message #93 received at 652011@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: Riku Voipio <riku.voipio@iki.fi>
Cc: debian-devel@lists.debian.org, 652011@bugs.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Thu, 15 Dec 2011 17:24:12 +0000
On Thu, Dec 15, 2011 at 07:17:53PM +0200, Riku Voipio wrote:
> On Thu, Dec 15, 2011 at 01:29:18PM +0000, Roger Leigh wrote:
> > Well, I think I still need persuading that this is the right direction
> > to move the files.  I still think that moving /usr to / is a better
> > strategy
> 
> I think we would need a very, very good reason to migrate away from /usr.
> Fedora already is going the other way (/lib,bin to /usr). Going the other
> way would increase fragmentation in Linux and make essentially FHS history.
> 
> Moving everything to /usr is also less work, no need to get rid of the
> --prefix=/usr in most packages in debian...

Hi Riku,

I think an important point to consider is that /usr would not
disappear.  It could be replaced by a symlink for new installs.
This would permit older installs to continue to use /usr, but
the files would end up on / for new installs.  So no changes
to --prefix would be needed, and the Debian packages themselves
could still provide files in /usr.

So none of this would break any FHS paths, or make us incompatible
with Fedora.  In both situations, the same files will be present
in /bin and /usr/bin (and the same for all common subdirectories).

Doing this would be a simple change to debian-installer.  It might
require a few other minor tweaks e.g. to dpkg-shlibdeps when
considering library search paths, but this isn't new--we've
already gone down this route for GNU/Hurd in the past.


Regards,
Roger
-- 
  .''`.  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.




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Thu, 15 Dec 2011 17:45:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Thu, 15 Dec 2011 17:45:05 GMT) Full text and rfc822 format available.

Message #98 received at 652011@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: debian-devel@lists.debian.org, 652011@bugs.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Thu, 15 Dec 2011 13:43:19 -0400
[Message part 1 (text/plain, inline)]
Roger Leigh wrote:
> I think an important point to consider is that /usr would not
> disappear.  It could be replaced by a symlink for new installs.
> This would permit older installs to continue to use /usr, but
> the files would end up on / for new installs.  So no changes
> to --prefix would be needed, and the Debian packages themselves
> could still provide files in /usr.

Didn't the hurd port try this several years ago? My impression was that
they didn't feel it had been worth the pain, perhaps it's not so easy.

-- 
see shy jo
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Thu, 15 Dec 2011 19:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thomas Goirand <thomas@goirand.fr>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Thu, 15 Dec 2011 19:30:03 GMT) Full text and rfc822 format available.

Message #103 received at 652011@bugs.debian.org (full text, mbox):

From: Thomas Goirand <thomas@goirand.fr>
To: 652011@bugs.debian.org
Cc: Debian Developers <debian-devel@lists.debian.org>
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Fri, 16 Dec 2011 03:27:16 +0800
On 12/15/2011 09:29 PM, Roger Leigh wrote:
> Well, I think I still need persuading that this is the right direction
> to move the files.  I still think that moving /usr to / is a better
> strategy, albeit introducing some problems with users who would need
> to resize the rootfs (but this has always been an issue with upgrades,
> it's really the admin's responsibility to deal with partition sizing
> prior to upgrading).
>   
This would be *really* a big issue for *a lot* of users. And I'd be one
of these
guys with about 100 servers to reinstall from scratch. I don't like using
a /boot partition, so I have a rootfs of 1 GB of RAID1, then home, usr,
var, tmp
and swap mounted on LVM over RAID10. Please don't do that unless you make
a special tool to resize my disks on-the-fly (eg: without shutting down my
running services).

Also, I really fail to see how this would be an improvement for our users.
It's just an argument for making our lives of lazy library maintainer
more easy.
Plus having very few tools on the boot partition makes it possible to store
them on a slower disk that will be less accessed than the faster one holding
your /usr (see my setup above, rootfs is RAID1, /usr is on RAID10, so my
/usr
is faster than the rootfs).

Thomas





Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Thu, 15 Dec 2011 19:36:15 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thomas Goirand <thomas@goirand.fr>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Thu, 15 Dec 2011 19:36:15 GMT) Full text and rfc822 format available.

Message #108 received at 652011@bugs.debian.org (full text, mbox):

From: Thomas Goirand <thomas@goirand.fr>
Cc: Debian Developers <debian-devel@lists.debian.org>, 652011@bugs.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Fri, 16 Dec 2011 03:35:55 +0800
On 12/16/2011 01:24 AM, Roger Leigh wrote:
> Hi Riku,
>
> I think an important point to consider is that /usr would not
> disappear.  It could be replaced by a symlink for new installs.
> This would permit older installs to continue to use /usr, but
> the files would end up on / for new installs.  So no changes
> to --prefix would be needed, and the Debian packages themselves
> could still provide files in /usr.
>   
Feel free to experiment such non-sense on your own computers,
but please do not impose this to everyone.

Oh, and when I'm at it, how do you implement /usr as read only,
(over nfs for example)? This is a quite common setup in large
organization / universities.
> Doing this would be a simple change to debian-installer.
And a hell for upgrades on *a lot* of existing systems.
>   It might
> require a few other minor tweaks
Yeah, right... A few other minor tweaks... Good luck with them!
Seriously, how much wrong could it go?

Thomas Goirand (zigo)





Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Thu, 15 Dec 2011 19:42:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Josselin Mouette <joss@debian.org>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Thu, 15 Dec 2011 19:42:08 GMT) Full text and rfc822 format available.

Message #113 received at 652011@bugs.debian.org (full text, mbox):

From: Josselin Mouette <joss@debian.org>
To: Thomas Goirand <thomas@goirand.fr>, 652011@bugs.debian.org
Cc: debian-devel@lists.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Thu, 15 Dec 2011 20:39:59 +0100
[Message part 1 (text/plain, inline)]
Le vendredi 16 décembre 2011 à 03:35 +0800, Thomas Goirand a écrit : 
> Oh, and when I'm at it, how do you implement /usr as read only,
> (over nfs for example)? This is a quite common setup in large
> organization / universities.

No, it is not. With a packaging system it is not suitable to have a
NFS-shared /usr.

OTOH it is a common setup to share / over NFS.

-- 
 .''`.      Josselin Mouette
: :' :
`. `'
  `-
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Thu, 15 Dec 2011 19:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Thu, 15 Dec 2011 19:54:03 GMT) Full text and rfc822 format available.

Message #118 received at 652011@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: debian-devel@lists.debian.org, 652011@bugs.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Thu, 15 Dec 2011 11:49:57 -0800
Thomas Goirand <thomas@goirand.fr> writes:

> Oh, and when I'm at it, how do you implement /usr as read only,
> (over nfs for example)? This is a quite common setup in large
> organization / universities.

I really don't believe this is true any more.  We used to do stuff like
this and stopped doing it a long time ago, and that's what I hear from my
peers.  Local disk space is cheap and local package management is now
easy, and doing this sort of trick is now really a waste of time and a
good way to make all your computers unnecessarily slow.

There are still some diskless systems, but those systems don't mount /usr
over NFS.  They mount / over NFS, which is a different problem entirely.

Mounting /usr but not / is not a diskless configuration; it's a very rare
hybrid mode with a small local disk, and now that local disk is so cheap
(even with embedded devices with flash memory), it's mostly just a bad
idea.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Thu, 15 Dec 2011 20:24:13 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Thu, 15 Dec 2011 20:24:13 GMT) Full text and rfc822 format available.

Message #123 received at 652011@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: Thomas Goirand <thomas@goirand.fr>, 652011@bugs.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Thu, 15 Dec 2011 21:22:30 +0100
[Message part 1 (text/plain, inline)]
On 15.12.2011 20:27, Thomas Goirand wrote:
> 
> Also, I really fail to see how this would be an improvement for our users.
> It's just an argument for making our lives of lazy library maintainer
> more easy.

The question is, if moving files around is a good way to spend
maintainers time. I think not. Our ressources are already stretched
thin, and there are better ways to invest our time.


> Plus having very few tools on the boot partition makes it possible to store
> them on a slower disk that will be less accessed than the faster one holding
> your /usr (see my setup above, rootfs is RAID1, /usr is on RAID10, so my
> /usr
> is faster than the rootfs).

You can keep /usr on a separate partition. You just need to use an
initramfs then, which will mount /usr.
Adding support for that to initramfs-tools should not be too hard.
dracut already supports this.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Thu, 15 Dec 2011 21:27:15 GMT) Full text and rfc822 format available.

Acknowledgement sent to Luca Capello <luca@pca.it>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Thu, 15 Dec 2011 21:27:15 GMT) Full text and rfc822 format available.

Message #128 received at 652011@bugs.debian.org (full text, mbox):

From: Luca Capello <luca@pca.it>
To: debian-devel@lists.debian.org
Cc: 652011@bugs.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Thu, 15 Dec 2011 22:25:17 +0100
[Message part 1 (text/plain, inline)]
Hi there!

On Thu, 15 Dec 2011 18:19:54 +0100, Marco d'Itri wrote:
> On Dec 15, Roger Leigh <rleigh@codelibre.net> wrote:
>
>> > You keep repeating arguments in favour of moving /{bin,sbin,lib}/ to
>> > /usr/ :-)
>> Well, I think I still need persuading that this is the right direction
>> to move the files.  I still think that moving /usr to / is a better
>> strategy, albeit introducing some problems with users who would need
> /usr to / does not allow any new features, while / to /usr allows
> implementing new features like creating OS snapshots at file system
> level (something which Fedora already supports) or a real complete OS
> image (to be NFS-shared, replicated, etc).

Maybe a naive comment, but I would say that there should be a list of
all the benefits for any change, being it / -> /usr or /usr -> /, then
deciding which is the Right Thing™ would be "easier" (doing so we can
also document our choices).

So THANK YOU Marco for explaining (another) one for / -> /usr, I was
thinking of asking Roger about it [1] before reading your reply ;-)

[1] <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652011#93>

Thx, bye,
Gismo / Luca
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Fri, 16 Dec 2011 00:21:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Fri, 16 Dec 2011 00:21:07 GMT) Full text and rfc822 format available.

Message #133 received at 652011@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: 652011@bugs.debian.org
Cc: debian-devel@lists.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Fri, 16 Dec 2011 00:17:30 +0000
On Fri, Dec 16, 2011 at 03:35:55AM +0800, Thomas Goirand wrote:
> On 12/16/2011 01:24 AM, Roger Leigh wrote:
> > Hi Riku,
> >
> > I think an important point to consider is that /usr would not
> > disappear.  It could be replaced by a symlink for new installs.
> > This would permit older installs to continue to use /usr, but
> > the files would end up on / for new installs.  So no changes
> > to --prefix would be needed, and the Debian packages themselves
> > could still provide files in /usr.
> >   

> > Doing this would be a simple change to debian-installer.
> And a hell for upgrades on *a lot* of existing systems.

The point of the above was to show that it could be made that upgrades
would be unaffected by the change: it would only occur for new
installs.  I'm not saying that's the only way or the best way, just
that it's one possibility to consider.


Regards,
Roger

-- 
  .''`.  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.




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Fri, 16 Dec 2011 10:27:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <goswin-v-b@web.de>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Fri, 16 Dec 2011 10:27:18 GMT) Full text and rfc822 format available.

Message #138 received at 652011@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <goswin-v-b@web.de>
To: Russ Allbery <rra@debian.org>
Cc: debian-devel@lists.debian.org, 652011@bugs.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Fri, 16 Dec 2011 11:25:28 +0100
Russ Allbery <rra@debian.org> writes:

> Zachary Harris <zacharyharris@hotmail.com> writes:
>
>> My understanding of the FHS would be that if a library is a dependency
>> of a binary in /bin or /sbin, then such library belongs in /lib, not
>> /usr/lib. (If for some reason the library is also desired in /usr/lib
>> then a sym link from /lib to /usr/lib, but not the other way around, is
>> acceptable.) A review of past bug reports (e.g. #633019 and #639939 from
>> this summer) shows that this policy gets repeatedly violated in Debian
>> until someone catches it.
>
> I'm increasingly convinced by the recent discussion on debian-devel that
> doing all the (rather substantial) work required to keep this separation
> working is a waste of our collective time.  We're not doing a very good
> job at it anyway, chasing all the library dependencies is a fair amount of
> work, and things have to keep moving around as dependencies change.  And
> this is all to support use cases that, while real, are fairly marginal in
> my estimation.  This does not seem like the most effective place for us to
> be spending our time.
>
> I don't know if it's worth the effort to unify /bin and /usr/bin or the
> other similar things that have been discussed from time to time, but I do
> think it may be time for Debian to just officially say that we don't
> support /usr on a (meaningfully) separate partition from /bin and /lib,
> and that binaries in /bin may have dependencies on /usr/lib.

Absolutely NO, NO, NO. You can't just break all the systems out there
that do have a seperate /usr partition.

And that isn't what was suggested. The suggested approach is to have
/usr mounted in initramfs (or in one of the first boot scripts).

So what Debian could officially say is that /usr will be mounted and
packages may freely use it at any time during boot. That the seperation
of / and /usr becomes unimportant because both will always be available.

But before any of that happens please first show us a working
implementation of mounting /usr from initramfs and as first thing during
boot. And that should probably be included in a stable release before
the seperation of / and /usr is declared meaningless.

MfG
        Goswin




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Fri, 16 Dec 2011 10:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <goswin-v-b@web.de>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Fri, 16 Dec 2011 10:45:06 GMT) Full text and rfc822 format available.

Message #143 received at 652011@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <goswin-v-b@web.de>
To: Roger Leigh <rleigh@codelibre.net>
Cc: 652011@bugs.debian.org, Zachary Harris <zacharyharris@hotmail.com>
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Fri, 16 Dec 2011 11:39:35 +0100
Roger Leigh <rleigh@codelibre.net> writes:

> On Wed, Dec 14, 2011 at 12:53:24PM -0500, Zachary Harris wrote:
>>   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.
>
> This is a bit beside the point.  People keep bringing up mounting /usr
> over NFS.  No one to date has provided a sensible use case for it.
> This is because "old timers" (or whoever) have failed to notice a
> fundamental flaw: *package management does not work with a shared /usr*.

The cluster setup I use at work uses an initramfs with all the essential
stuff in it and mounts the rest over NFS. The reason why this works is
that the / is just as shared as /usr. Just one is shared via pxe and
then other via NFS.

The reason for not having everything on NFS is to reduce network load
and that nodes should be minimally functional without NFS. Esspecially
that you can still log in as root and diagnose problems.

> On a Debian there are really only two categories for partitions:
> those under the control of the package manager, and those which
> are not (user data etc.).  Does it make sense to split package-managed
> files over multiple partitions? (other than /var)
>
> This is *the* key point.  Under a package managed distribution /
> and /usr are part of a *managed whole*.  They can't exist separately,
> even if they are on different partitions, mounted over NFS, or
> whatever.  It's fine that such things /work/, but we do need to
> question /why/ one would do such a thing.  If you're mounting /usr
> over NFS, the real question is "why aren't you mounting / over NFS,
> which also then includes /usr?".  Mounting /usr separately makes no
> sense *at all*.
>
> The same argument applies to encryption.  / and /usr both contain a
> selection of programs, libraries etc.  If you're encrypting one, why
> would you not encrypt all of it?  And the same for mounting read-only.

/, specifically /etc, contains sensitive information so it has to be
encrypted. /usr on the other hand does not and encrypting it is just a
waste of cpu time.

This would actually call for having /etc a seperate (encrypted)
partition and /usr not. Encrypting /bin or /lib is indeed as useless as
/usr.

> The question that needs answering is this:
>
>   "what are the reasons, today, for a separate /usr?"
>
> Excluding "historical practice".  What real function does it have?
> Does it have any reason to continue to exist?
>
> And regarding the LSB: I checked, and it would be entirely compliant
> for Debian to merge the two.
>
>> 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).")
>
> The problem here is, can we /be/ consistent?  What is one system's
> essential package required for bringing up a working system is
> someone else's occasionally-used tool that's not important at all.
> Yet both might be required to be on the rootfs.  We can't be all
> things to all people in the current state.  But unification /would/
> *guarantee* things would always work and be consistent: every
> program and library would always be right there on the rootfs.

You are not reading him.

consistent == if it is in /sbin or /bin then it works without /usr.

consistent != everything even some insane user might want in / is in /.

That was exactly his point.

> The status quo is a "best effort".  Things sometimes break, and
> there's an continuing migration of "essential" packages to the
> rootfs.  Given that a modern initramfs can mount pretty much any
> filesystem, either locally or over a network, what's the *real*
> reason for a separate /usr?  It's certainly not for any booting-
> related reason.

MfG
        Goswin




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Fri, 16 Dec 2011 11:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Roger Leigh <rleigh@codelibre.net>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Fri, 16 Dec 2011 11:09:08 GMT) Full text and rfc822 format available.

Message #148 received at 652011@bugs.debian.org (full text, mbox):

From: Roger Leigh <rleigh@codelibre.net>
To: debian-devel@lists.debian.org
Cc: 652011@bugs.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Fri, 16 Dec 2011 11:07:32 +0000
On Thu, Dec 15, 2011 at 06:19:54PM +0100, Marco d'Itri wrote:
> On Dec 15, Roger Leigh <rleigh@codelibre.net> wrote:
> 
> > > You keep repeating arguments in favour of moving /{bin,sbin,lib}/ to
> > > /usr/ :-)
> > Well, I think I still need persuading that this is the right direction
> > to move the files.  I still think that moving /usr to / is a better
> > strategy, albeit introducing some problems with users who would need
> /usr to / does not allow any new features, while / to /usr allows
> implementing new features like creating OS snapshots at file system
> level (something which Fedora already supports) or a real complete OS
> image (to be NFS-shared, replicated, etc).

I'm not quite sure I see why such new features would be dependent upon
this.

Please correct my confusion if I'm wrong, but I'm not sure I can see
why it wouldn't be possible to snapshot the rootfs whichever way we
migrate files.  Both / and /usr would need to be snapshotted as a whole
in order to do proper rollbacks wouldn't they?  So why would migrating
from /usr to / prevent this?

> > WRT mounting additional filesystems in the initramfs, how difficult
> > would it be to add an additional mount option to /etc/fstab entries,
> > e.g. "init" or "initramfs" to mark them as being required for mounting
> > in the initramfs.  This could include /, /usr, /etc and anything else
> > the admin deems necessary for booting, and would just be checked and
> > added when creating/updating the initramfs.
> / is already mountable, while /etc obviously could not be if you want to
> look at fstab. I see no compelling reasons to create standalone file
> systems for the other directories, which are small and static.

If we could add an entry such as:

  /dev/mapper/etc  /etc  ext4  initramfs  0  1

to /etc/fstab, then it could be added to a list of filesystems to be
mounted in the initramfs.  Obviously a change to /etc/fstab would
require the initramfs to be updated, but when it came to mounting the
rest of the filesystems once the initramfs hands over to the rootfs
init, it could continue to use the real /etc/fstab.  The only real
change would be that certain filesystems would have been pre-mounted.


Regards,
Roger

-- 
  .''`.  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.




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Fri, 16 Dec 2011 17:06:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to md@Linux.IT (Marco d'Itri):
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Fri, 16 Dec 2011 17:06:03 GMT) Full text and rfc822 format available.

Message #153 received at 652011@bugs.debian.org (full text, mbox):

From: md@Linux.IT (Marco d'Itri)
Cc: debian-devel@lists.debian.org, 652011@bugs.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Fri, 16 Dec 2011 18:02:22 +0100
[Message part 1 (text/plain, inline)]
On Dec 16, Roger Leigh <rleigh@codelibre.net> wrote:

> Please correct my confusion if I'm wrong, but I'm not sure I can see
> why it wouldn't be possible to snapshot the rootfs whichever way we
> migrate files.  Both / and /usr would need to be snapshotted as a whole
> in order to do proper rollbacks wouldn't they?  So why would migrating
> from /usr to / prevent this?
Obviously it depends on what you are trying to do, but the interesting
case for me is to snapshot the OS (/usr) but keep the data and
configuration (everything else).
And keeping /etc, /home and /var on a different file system to allow
snapshotting / is more complex (and not really feasible for /etc).

And then there is the issue of easily sharing the OS (either over the
network or replicating it) while keeping distinct copies of local data.

> If we could add an entry such as:
> 
>   /dev/mapper/etc  /etc  ext4  initramfs  0  1
> 
> to /etc/fstab, then it could be added to a list of filesystems to be
> mounted in the initramfs.  Obviously a change to /etc/fstab would
> require the initramfs to be updated, but when it came to mounting the
Indeed. So this still looks like a very complex solution to a problem
nobody cares about.

-- 
ciao,
Marco
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Thu, 22 Dec 2011 03:03:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Thu, 22 Dec 2011 03:03:04 GMT) Full text and rfc822 format available.

Message #158 received at 652011@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: debian-devel@lists.debian.org, 652011@bugs.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Thu, 22 Dec 2011 04:00:44 +0100
Hi!

On Thu, 2011-12-15 at 13:43:19 -0400, Joey Hess wrote:
> Roger Leigh wrote:
> > I think an important point to consider is that /usr would not
> > disappear.  It could be replaced by a symlink for new installs.
> > This would permit older installs to continue to use /usr, but
> > the files would end up on / for new installs.  So no changes
> > to --prefix would be needed, and the Debian packages themselves
> > could still provide files in /usr.
> 
> Didn't the hurd port try this several years ago? My impression was that
> they didn't feel it had been worth the pain, perhaps it's not so easy.

The old default was changed for GNU/Hurd not because the setup in itself
was considered particularly painful, more because doing so for a single
port w/o getting the distribution at large to agree this was something
worth supporting was painful as overwrite problems were continuously
introduced.

regards,
guillem




Information forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org:
Bug#652011; Package general. (Thu, 22 Dec 2011 11:04:19 GMT) Full text and rfc822 format available.

Acknowledgement sent to Goswin von Brederlow <goswin-v-b@web.de>:
Extra info received and forwarded to list. Copy sent to debian-devel@lists.debian.org. (Thu, 22 Dec 2011 11:04:25 GMT) Full text and rfc822 format available.

Message #163 received at 652011@bugs.debian.org (full text, mbox):

From: Goswin von Brederlow <goswin-v-b@web.de>
To: debian-devel@lists.debian.org
Cc: 652011@bugs.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Thu, 22 Dec 2011 11:59:30 +0100
Guillem Jover <guillem@debian.org> writes:

> Hi!
>
> On Thu, 2011-12-15 at 13:43:19 -0400, Joey Hess wrote:
>> Roger Leigh wrote:
>> > I think an important point to consider is that /usr would not
>> > disappear.  It could be replaced by a symlink for new installs.
>> > This would permit older installs to continue to use /usr, but
>> > the files would end up on / for new installs.  So no changes
>> > to --prefix would be needed, and the Debian packages themselves
>> > could still provide files in /usr.
>> 
>> Didn't the hurd port try this several years ago? My impression was that
>> they didn't feel it had been worth the pain, perhaps it's not so easy.
>
> The old default was changed for GNU/Hurd not because the setup in itself
> was considered particularly painful, more because doing so for a single
> port w/o getting the distribution at large to agree this was something
> worth supporting was painful as overwrite problems were continuously
> introduced.
>
> regards,
> guillem

Plus you can not ship /usr as symlink in one package and as directory in
others. That triggers a file overwrite error during update (for the
package containing the symlink). We had this problem with packages
shipping files in /lib64 or /usr/lib64 in the past several times.

So if /usr is a symlink then everyone has to change to --prefix=/.
That is what makes linking /bin and /sbin to /usr/* easier. Less
packages to change.

MfG
        Goswin





Bug reassigned from package 'general' to 'debian-policy'. Request was from Holger Levsen <holger@layer-acht.org> to control@bugs.debian.org. (Tue, 29 May 2012 07:48:17 GMT) Full text and rfc822 format available.

Severity set to 'important' from 'serious' Request was from Holger Levsen <holger@layer-acht.org> to control@bugs.debian.org. (Tue, 29 May 2012 08:03:08 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#652011; Package debian-policy. (Sat, 11 Aug 2012 03:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Zachary Harris <zacharyharris@hotmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 11 Aug 2012 03:09:03 GMT) Full text and rfc822 format available.

Message #172 received at 652011@bugs.debian.org (full text, mbox):

From: Zachary Harris <zacharyharris@hotmail.com>
To: 652011@bugs.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Fri, 10 Aug 2012 23:05:32 -0400
[Message part 1 (text/plain, inline)]
  After some time, I've recently gotten back to tackling the FHS dynamic library dependency issue for separate root and usr partitions.

  Testing release 0.1.3 of my FHS-utils package is available at git://everythingwiki.sytes.net/fhs-utils. It currently consists of three commands:

fhscheck - check system for FHS compliance [that's an overstatement, but it checks a couple things, anyway]
fhslibcomply - make essential libraries accessible in root partition
undofhslibcomply - safely undo changes made by fhslibcomply

  For anyone interested, I hope you will find the documentation in the man pages, README, and code itself to be decent enough to be worth giving the package a moment of consideration. Although I personally think it is pretty well done, neither dynamic-linking related issues nor Perl programming have previously been areas of specialization for me (i.e. I'm still learning), so forgive me for any dumb stuff in there.

  fhslibcomply accomplishes the goal that I wished to achieve. Basically, it finds executables in /{s,}bin which have dynamic linked dependencies in /usr, copies the needed /usr libraries to somewhere in /lib*, and documents the process so it can be reverted later, or whatever. With the help of fhslibcomply, the command:

find /*bin -type f -exec ldd '{}' \; |& grep /usr/ | wc -l

will now return 0 on my various Squeeze and Sid machines, rather than than the positive (16,22,24) values I would see without it. Thus I can now boot in to my encrypted root partition without seeing the errors I used to see involving libraries that live in the later-to-be-mounted /usr.

  I'm happy with how the package works for me personally from the command line. What something like FHS-utils could mean for helping a distro like Debian maintain general FHS compliance on user systems is yet another question entirely. Possibilities include:
1) The fhscheck tool could simply be used by package maintainers to help guide decisions about where to install their libraries (/usr/lib vs. /lib).
2) At the much more intrusive end of the spectrum, some variant of the present fhslibcomply could be triggered every time new packages are installed or removed to see if the overall set of dependencies between / and /usr has changed, and (at least on systems with separate mounts) make any necessary copies, say, from the one to the other, so that the root partition always has all of the libraries it needs (as defined by /sbin and /bin).
3) Etc.

  I am as yet not a DM myself, and maintaining a package that mucks around with essential system components would obviously be jumping quite into the deep end of things. If there are any DD's out there who find this subject interesting and would like to work with me on it, I will be delighted to hear from you.

-Zach


[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#652011; Package debian-policy. (Sat, 11 Aug 2012 03:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 11 Aug 2012 03:48:03 GMT) Full text and rfc822 format available.

Message #177 received at 652011@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: 652011@bugs.debian.org
Subject: Re: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
Date: Fri, 10 Aug 2012 20:46:10 -0700
Zachary Harris <zacharyharris@hotmail.com> writes:

>   I'm happy with how the package works for me personally from the
>   command line. What something like FHS-utils could mean for helping a
>   distro like Debian maintain general FHS compliance on user systems is
>   yet another question entirely. Possibilities include:

> 1) The fhscheck tool could simply be used by package maintainers to help
> guide decisions about where to install their libraries (/usr/lib
> vs. /lib).

As a package maintainer, I'd be very interested in the results of this run
across the archive to pick up problems with various packages, similar to
how we do with debcheck and the like.  It's easy to miss problems like
this due to newly-introduced upstream dependencies on things.

I realize there's a larger debate at the moment over whether this
distinction is useful, but until we make a clear decision to stop
supporting it, it's nice to have tools to help us support what we're
currently supporting.  And it also makes it clear how large of a problem
we have with following this separation, which can inform the decision of
whether to continue to support it.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Severity set to 'wishlist' from 'important' Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Sun, 12 Aug 2012 18:30:05 GMT) Full text and rfc822 format available.

Changed Bug title to 'consider dropping the separation between /bin and /usr/bin, and /lib and /usr/lib' from 'general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib' Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Sun, 12 Aug 2012 18:36:05 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#652011; Package debian-policy. (Fri, 17 Aug 2012 00:06:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Zachary Harris <zacharyharris@hotmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 17 Aug 2012 00:06:03 GMT) Full text and rfc822 format available.

Message #186 received at 652011@bugs.debian.org (full text, mbox):

From: Zachary Harris <zacharyharris@hotmail.com>
To: 652011@bugs.debian.org
Subject: consider dropping the separation between /bin and /usr/bin, and /lib and /usr/lib ...
Date: Thu, 16 Aug 2012 20:03:28 -0400
I would propose:

  1) /bin vs. /usr/bin (likewise for sbin) is both subjective and
context dependent. It is subjective because it may be *possible* to do
certain essential tasks with a certain minimal set of tools, but far
*easier* or *preferable* to get them done with a larger set. The ability
to perform certain essential tasks is also a function of the knowledge
and creativity of the sys admin: FHS 2.3 provides the example of using
"echo *" as a replacement for "ls". It is context dependent because, for
example, tools related to mounting various types of file systems would
be essential only on machines that access a /usr that is stored on such
a fs.

  2) Therefore, it is impossible for a distro with as wide of an
audience as Debian to partition executables into /bin and /usr/bin in a
way that would be considered "correct" for all users.

  3) *On a given system*, the partition of libraries into /lib vs.
/usr/lib can be defined objectively as a function of /bin (and /sbin).
However, since the latter is itself dependent on the set of locally
installed packages, as well as on the subjective factors mentioned
above, it is therefore impossible to partition /lib vs. /usr/lib *at the
distro level* in a manner which will give rise to the objectively
defined, locally "correct" partition on all installations. [Given the
set of all executables in /{s,}bin in all Debian packages at a given
time, it is possible to define a minimal set of libraries for /lib such
that all essential libraries will certainly be accessible in a root
partition. However, such a "globally defined /lib" then gives rise to
the possibility of an overly inflated /lib on local machines which don't
have every possible /bin package installed.]

  4) The above does not imply that it is wrong to continue with the
status quo of Debian respecting the / vs. /usr distinction and seeking
to put libraries and executables in locations which are *sensible* at
the universal level and will *generally* work just fine on the majority
of installations.

  As a multi-partition guy myself, I believe I must concede that is it
impossible for Debian package maintainers to know where the binaries
that I install on my machine "should" go. It seems that if I need to
support a / vs. /usr distinction on a Debian system, then rather than
expecting the package maintainers to "get it right" as defined for me
locally, I instead need to find an appropriate way to get my specific
context to interact with the generic package managed environment (which
was the intention of my fhs-utils package).

  Personally, then, I would cast a vote for continuing on with the
status quo of Debian supporting the / vs. /usr distinction with a
"generically reasonable" partitioning of binary files into their
respective locations, with a note in section 9.1.1 (File System
Structure---exceptions) of Debian Policy to this effect.

-Zach




Marked as found in versions debian-policy/3.9.1.0. Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Wed, 29 Aug 2012 04:33:04 GMT) Full text and rfc822 format available.

Merged 652011 686143 Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Wed, 29 Aug 2012 04:33:05 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#652011; Package debian-policy. (Wed, 29 Aug 2012 05:15:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Zachary Harris <zacharyharris@hotmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Wed, 29 Aug 2012 05:15:06 GMT) Full text and rfc822 format available.

Message #195 received at 652011@bugs.debian.org (full text, mbox):

From: Zachary Harris <zacharyharris@hotmail.com>
To: 652011@bugs.debian.org, rra@debian.org
Subject: Please revert original bug title
Date: Wed, 29 Aug 2012 01:13:05 -0400
Russ,

  Not only is your new title for this bug a different (though related)
issue from the original bug report, the new title is in fact
contradictory to, and incompatible with, the problem that the original
bug was addressing. I am using 8G in /usr and the entire root partition
is 2G. If the separation was dropped, where would I put my binaries?
  If dropping the separation is on *your* wishlist, please open a new
bug report for that. But your wish doesn't work with my present
configuration, which presently *is* supposed to be supported by Debian.
So unless and until your wish is granted at Debian, I believe my bug
report in its original form still stands. Please revert.

-Zach




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#652011; Package debian-policy. (Wed, 29 Aug 2012 05:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Wed, 29 Aug 2012 05:45:03 GMT) Full text and rfc822 format available.

Message #200 received at 652011@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Zachary Harris <zacharyharris@hotmail.com>
Cc: 652011@bugs.debian.org
Subject: Re: Please revert original bug title
Date: Tue, 28 Aug 2012 22:40:17 -0700
unmerge 652011
retitle 652011 general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
reassign 652011 general
# effectively unresolvable as a general bug; to further pursue this would
# require specific bugs filed against specific packages
close 652011
thanks

Zachary Harris <zacharyharris@hotmail.com> writes:

>   Not only is your new title for this bug a different (though related)
> issue from the original bug report, the new title is in fact
> contradictory to, and incompatible with, the problem that the original
> bug was addressing. I am using 8G in /usr and the entire root partition
> is 2G. If the separation was dropped, where would I put my binaries?
>   If dropping the separation is on *your* wishlist, please open a new
> bug report for that. But your wish doesn't work with my present
> configuration, which presently *is* supposed to be supported by Debian.
> So unless and until your wish is granted at Debian, I believe my bug
> report in its original form still stands. Please revert.

Fair enough.  In that case, I'm going to just close this bug on the
grounds that there's nothing debian-policy can do about your original
report.  Policy already says what you want it to say currently, and a bug
against general for the overall class of problem is essentially completely
futile in Debian -- it won't produce any meaningful result.  So,
basically, this bug has wandered off in a completely different direction
than you intended, and I don't think it's still doing anyone any good.

We didn't arrive at any conclusion about dropping the separation and no
one is pursuing this right now, so I don't think there's much point in
keeping the wishlist bug against Policy open anyway.  We can always file a
new bug if we want to pursue the problem.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Disconnected #652011 from all other report(s). Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Wed, 29 Aug 2012 05:45:05 GMT) Full text and rfc822 format available.

Changed Bug title to 'general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib' from 'consider dropping the separation between /bin and /usr/bin, and /lib and /usr/lib' Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Wed, 29 Aug 2012 05:45:06 GMT) Full text and rfc822 format available.

Bug reassigned from package 'debian-policy' to 'general'. Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Wed, 29 Aug 2012 05:45:06 GMT) Full text and rfc822 format available.

No longer marked as found in versions debian-policy/3.9.1.0. Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Wed, 29 Aug 2012 05:45:07 GMT) Full text and rfc822 format available.

Marked Bug as done Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Wed, 29 Aug 2012 05:45:07 GMT) Full text and rfc822 format available.

Notification sent to Zachary Harris <zacharyharris@hotmail.com>:
Bug acknowledged by developer. (Wed, 29 Aug 2012 05:45:08 GMT) Full text and rfc822 format available.

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Wed, 26 Sep 2012 07:26:29 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sat Apr 19 09:45:00 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.