Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian Development (http://www.linux-archive.org/debian-development/)
-   -   Stuff from /bin, /sbin, /lib depending on /usr/lib libraries (http://www.linux-archive.org/debian-development/699004-stuff-bin-sbin-lib-depending-usr-lib-libraries.html)

Russ Allbery 08-29-2012 09:34 PM

Stuff from /bin, /sbin, /lib depending on /usr/lib libraries
 
Jakub Wilk <jwilk@debian.org> writes:

> I analysed all binaries and libraries shipped in /bin, /sbin and /lib to
> find stuff that requires libraries from /usr/lib. Please see the
> attachments for results (unstable, i386).

> Russ Allbery <rra@debian.org>
> libpam-afs-session
> libpam-heimdal
> libpam-krb5
> libpam-shishi (U)

Oh, huh, yes. This raises an interesting question. All PAM modules are
installed under /lib, because that's the path used by libpam to load them.
However, I don't think the vast majority of PAM modules could be
considered critical for early boot or need to be usable without /usr
mounted, and the thought of moving all libraries referred to by any PAM
module into /lib is daunting.

Should we just generally except them from this requirement? Or do
something more subtle?

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87ipc1mlfs.fsf@windlord.stanford.edu">http://lists.debian.org/87ipc1mlfs.fsf@windlord.stanford.edu

Eric Dorland 08-29-2012 09:40 PM

Stuff from /bin, /sbin, /lib depending on /usr/lib libraries
 
* Jakub Wilk (jwilk@debian.org) wrote:
> I analysed all binaries and libraries shipped in /bin, /sbin and
> /lib to find stuff that requires libraries from /usr/lib. Please see
> the attachments for results (unstable, i386).

[snip]

> Eric Dorland <eric@debian.org>
> libpam-p11

[snip]

I think PAM modules have to live in /lib/security. Happy to move
things to /usr/lib/security if that's possible.

--
Eric Dorland <eric@kuroneko.ca>
ICQ: #61138586, Jabber: hooty@jabber.com

Peter Samuelson 08-29-2012 10:31 PM

Stuff from /bin, /sbin, /lib depending on /usr/lib libraries
 
[Russ Allbery]
> All PAM modules are installed under /lib, because that's the path
> used by libpam to load them. However, I don't think the vast
> majority of PAM modules could be considered critical for early boot
> or need to be usable without /usr mounted

It seems pam already looks in both /lib/security and /lib/{triplet}/security.
Why not add /usr/lib/{triplet}/security to the mix? (No need for
unqualified /usr/lib/security, I think. It seems GCJ already owns that
directory anyway.)

Peter


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120829223128.GA4352@p12n.org">http://lists.debian.org/20120829223128.GA4352@p12n.org

Michael Biebl 08-29-2012 11:02 PM

Stuff from /bin, /sbin, /lib depending on /usr/lib libraries
 
On 30.08.2012 00:31, Peter Samuelson wrote:
>
> [Russ Allbery]
>> All PAM modules are installed under /lib, because that's the path
>> used by libpam to load them. However, I don't think the vast
>> majority of PAM modules could be considered critical for early boot
>> or need to be usable without /usr mounted
>
> It seems pam already looks in both /lib/security and /lib/{triplet}/security.
> Why not add /usr/lib/{triplet}/security to the mix?

Imho moving pam modules around is just wasted (maintainer) time.
A much more sensible approach is to just lift the /-vs-/usr restriction.
The obvious way is to not use a separate /usr anymore or simply mount
/usr via the initramfs.

Wasn't there a patch for initramfs-tools floating around doing that?

Michael


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

Russ Allbery 08-29-2012 11:06 PM

Stuff from /bin, /sbin, /lib depending on /usr/lib libraries
 
Michael Biebl <biebl@debian.org> writes:

> Imho moving pam modules around is just wasted (maintainer) time.
> A much more sensible approach is to just lift the /-vs-/usr restriction.

We just had a long discussion about this. I think it's fairly safe to say
that while there are a number of people who think the distinction is not
particularly meaningful, there are others who still use it for various
reasons, and there's no consensus for doing this right now.

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 876281l2mp.fsf@windlord.stanford.edu">http://lists.debian.org/876281l2mp.fsf@windlord.stanford.edu

Roger Leigh 08-29-2012 11:11 PM

Stuff from /bin, /sbin, /lib depending on /usr/lib libraries
 
On Thu, Aug 30, 2012 at 01:02:39AM +0200, Michael Biebl wrote:
> On 30.08.2012 00:31, Peter Samuelson wrote:
> >
> > [Russ Allbery]
> >> All PAM modules are installed under /lib, because that's the path
> >> used by libpam to load them. However, I don't think the vast
> >> majority of PAM modules could be considered critical for early boot
> >> or need to be usable without /usr mounted
> >
> > It seems pam already looks in both /lib/security and /lib/{triplet}/security.
> > Why not add /usr/lib/{triplet}/security to the mix?
>
> Imho moving pam modules around is just wasted (maintainer) time.
> A much more sensible approach is to just lift the /-vs-/usr restriction.
> The obvious way is to not use a separate /usr anymore or simply mount
> /usr via the initramfs.
>
> Wasn't there a patch for initramfs-tools floating around doing that?

I started looking into it while doing the /run-in-initramfs stuff
last year, but didn't get anything working at the time--initramfs-
tools needs refactoring to remove the assumption that only one
filesystem will be mounted, before we can mount /usr as well
(and also maybe /etc). There was also the question about where
the information for mounting /usr should come from; IIRC at the
time we opted to use /etc/fstab from the rootfs, so that only the
location of the rootfs needs passing to the initramfs.

While I ran out of time back then for doing this (finishing my PhD),
it's definitely something I'd like as a release goal for jessie. If
the initramfs-tools maintainers won't have time for it, I can
certainly look into this further.


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


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

08-29-2012 11:15 PM

Stuff from /bin, /sbin, /lib depending on /usr/lib libraries
 
On Aug 30, Michael Biebl <biebl@debian.org> wrote:

> The obvious way is to not use a separate /usr anymore or simply mount
> /usr via the initramfs.
>
> Wasn't there a patch for initramfs-tools floating around doing that?
Yes, there is one but the maintainer has not applied or rejected it
so far.

Fellow developers, please do not waste your time moving stuff to /lib:
it's a task both endless and futile because nowadays it is clear that
the upstream maintainers of various stuff do not support a standalone
/usr mounted by the init scripts: if /usr is a standalone file system
then it must be mounted in the initramfs.
So let's just fix initramfs-tools and be done with this forever.

--
ciao,
Marco

"brian m. carlson" 08-29-2012 11:45 PM

Stuff from /bin, /sbin, /lib depending on /usr/lib libraries
 
On Thu, Aug 30, 2012 at 01:15:32AM +0200, Marco d'Itri wrote:
> Fellow developers, please do not waste your time moving stuff to /lib:
> it's a task both endless and futile because nowadays it is clear that
> the upstream maintainers of various stuff do not support a standalone
> /usr mounted by the init scripts: if /usr is a standalone file system
> then it must be mounted in the initramfs.
> So let's just fix initramfs-tools and be done with this forever.

Upstream maintainers of various stuff also refuse to provide man pages.
Debian does not always do what upstream wants.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

Michael Biebl 08-30-2012 12:00 AM

Stuff from /bin, /sbin, /lib depending on /usr/lib libraries
 
On 30.08.2012 01:45, brian m. carlson wrote:
> On Thu, Aug 30, 2012 at 01:15:32AM +0200, Marco d'Itri wrote:
>> Fellow developers, please do not waste your time moving stuff to /lib:
>> it's a task both endless and futile because nowadays it is clear that
>> the upstream maintainers of various stuff do not support a standalone
>> /usr mounted by the init scripts: if /usr is a standalone file system
>> then it must be mounted in the initramfs.
>> So let's just fix initramfs-tools and be done with this forever.
>
> Upstream maintainers of various stuff also refuse to provide man pages.
> Debian does not always do what upstream wants.

Providing man pages (if written well) does provide value, shuffling bits
around in the file system does not.

Michael


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

Russ Allbery 08-30-2012 12:15 AM

Stuff from /bin, /sbin, /lib depending on /usr/lib libraries
 
Michael Biebl <biebl@debian.org> writes:
> On 30.08.2012 01:45, brian m. carlson wrote:

>> Upstream maintainers of various stuff also refuse to provide man pages.
>> Debian does not always do what upstream wants.

> Providing man pages (if written well) does provide value, shuffling bits
> around in the file system does not.

And yet, when we discussed this just a little bit ago, several people
asked to keep the distinction because, for them, it provides value.

This sort of argument (which I also do myself sometimes) is kind of
frustrating. I understand what you mean: you believe the value provided
is not sufficient to warrant the effort. I am even somewhat inclined to
agree with you. But that's not what you're *saying*. I think there's a
natural human tendency to feel like any moderation or weakening of a
position provides openings for people to disagree, so we end up
"tightening" the argument by making it more absolute, leaving out all the
wiggle room. In the process, it often becomes inaccurate.

I think there's an open question on whether it's worth the effort to
support use cases for a separate /usr, but people aren't saying to keep
support for a separate /usr just out of meaningless consistency or because
they want other developers to waste time.

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 876281jkus.fsf@windlord.stanford.edu">http://lists.debian.org/876281jkus.fsf@windlord.stanford.edu


All times are GMT. The time now is 02:31 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.