[lsb-discuss] Proposed extensions to filesystem layout: LSB as successor to FHS?

Steve Langasek vorlon at debian.org
Mon Feb 28 17:58:38 PST 2011

Hi, Jeff!

On Mon, Feb 21, 2011 at 03:32:52PM -0500, Jeff Licquia wrote:
> On 02/17/2011 04:50 PM, Steve Langasek wrote:

> > As a first step towards standardization, we're trying to address the fact
> > that there exists no reliable one-to-one mapping between ABI-incompatible
> > library stacks and standard names on the filesystem.  I'd like to present
> > this WG with a draft proposal to address this:

> >    http://wiki.debian.org/Multiarch/Tuples

> > Would there be any interest within the LSB WG in picking this up as a
> > cross-vendor standard?

> I think there is interest (I'm interested, at any rate).

> It seems we have two problems here.  One: does implementing such a 
> proposal violate the FHS as currently written?  Two: can the people 
> behind this proposal get some wider buy-in, and can the LSB/FHS help 
> with that?

> By my reading of the FHS, there is no reason why Debian's multiarch spec 
> would violate the FHS by itself, as long as the original spec continues 
> to be followed.  Practically speaking, this would mean that a system 
> fully converted to the multiarch spec would maintain symlinks in /lib to 
> libc, and the dynamic linker would continue to recognize libraries 
> installed into bare /lib and /usr/lib.  (I'm assuming that the dynamic 
> linker itself would stay where it is.)

Sorry, let's break this down a bit.

What http://wiki.debian.org/Multiarch/Tuples proposes is not the use of any
particular directory layout on the filesystem; rather, this is a proposal
for a standard that would provide a 1:1 mapping between system ABIs and
strings so that we have a way of unambiguously talking about ABIs.  Now, the
underlying rationale for *wanting* such a mapping is to be able to use it on
the filesystem, for multiarch library paths in particular; but that comes
later, once we actually have a stable mapping that we can use for our
preliminary real-world implementation.

Of course, after starting this thread here, I immediately started to get
pushback from folks who feel that the GNU triplets *should* be the 1:1
mapping for system ABIs, and that where they aren't those are bugs that
should be fixed.  That led to a thread on the GCC upstream list, which seems
to be getting more traction than the previous one regarding armhf:


But that still leaves x86 a mess, and Matthias Klose, the gcc maintainer for
Debian and Ubuntu, believes that trying to change the triplet for the x86_32
port to the "sensible" i386-linux-gnu would trigger regressions.  So since
changing the system triplet without the gcc maintainer's support is a
non-starter, I'm still interested in discussing whether there should be a
mapping external to the GNU triplets for this purpose, and whether the LSB
WG is the right standards body to maintain such a mapping.

Now, as for the question of whether the Debian implementation is going to
comply with the current FHS:  it certainly will /not/ do so.  Packages are
going to need to *move* their libraries to the proposed new directories, not
keep backwards-compatible symlinks, because such symlinks would conflict
across architectures except in the special-cased 32/64 biarch pairings.

This includes moving libc, which carries the same filename on nearly all
architectures; but I don't think libc is a special case here (/lib/libc.so.*
is marked "optional" in the FHS).  The runtime linker will as you surmised
remain in the historic location for binary compatibility (making certain
esoteric multiarch pairings impossible due to conflicting linker names).
The library paths for ld.so will likewise include /usr/lib and /lib by
default for the foreseeable future, although libraries installed to the
multiarch paths would take precedence.

I don't think this is going to be a very high barrier to getting it
implemented in Debian; Debian already disagrees with the FHS where x86_64
libraries are concerned, so a further divergence (particularly with the hope
of eventual reconciliation) is not going to be too controversial.

> As for advocacy, we're a bit conservative about pushing our own ideas 
> around; we've been accused of shoving standards down people's throats a 
> few too many times (justly or no).  OTOH, if the other major distros 
> weren't opposed to the idea, we wouldn't mind helping to clear away 
> roadblocks.

> It would be interesting to gauge the reaction of the other distros on 
> the distributions list (distributions at lists.freedesktop.org).  A quick 
> search doesn't seem to turn up any previous discussions.

Right.  My aims regarding the LSB WG and multiarch are:

 1) reach a high-level agreement on how system ABIs should be represented as
    filesystem-friendly strings
 2) adapt the FHS to recognize multiarch library paths as a permitted
    deviation from current practice (possibly with a statement that, if
    you're going to try to support multiarch library combinations, this is
    the blessed way to do it)
 3) subject to widespread multiarch adoption by other distributions,
    deprecate lib{32,64}.

If this mailing list is not a good place to reach interested distro folks
for comment on the design, I'm happy to take the discussion to
distributions@ instead; but I don't think that's going to be the right forum
for tuple standardization in any case.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
Url : http://lists.linux-foundation.org/pipermail/lsb-discuss/attachments/20110228/6a537866/attachment.pgp 

More information about the lsb-discuss mailing list