Debian Bug report logs - #542865
Grant an FHS exception for the multiarch library directories

version graph

Package: debian-policy; Maintainer for debian-policy is Debian Policy List <debian-policy@lists.debian.org>; Source for debian-policy is src:debian-policy.

Reported by: Steve Langasek <vorlon@debian.org>

Date: Fri, 21 Aug 2009 21:54:02 UTC

Severity: wishlist

Found in version debian-policy/3.8.3.0

Fixed in version debian-policy/3.8.4.0

Done: Bill Allombert <ballombe@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 Policy List <debian-policy@lists.debian.org>:
Bug#542865; Package debian-policy. (Fri, 21 Aug 2009 21:54:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
New Bug report received and forwarded. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 21 Aug 2009 21:54:05 GMT) Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@debian.org>
To: submit@bugs.debian.org
Subject: Grant an FHS exception for the multiarch library directories
Date: Fri, 21 Aug 2009 14:51:20 -0700
[Message part 1 (text/plain, inline)]
Package: debian-policy
Version: 3.8.3.0

We are approaching the point at which it will be useful to begin having
packages in the archive that install to the multiarch library paths
({/usr,}/lib/<triplet>), for use with the multiarch-capable package manager
that's in progress.  However, installing libraries to these paths instead of
directly under {/usr,}/lib is an FHS violation and therefore is currently a
Policy violation as well.

The following patch grants an exception to the FHS while strictly defining
the conditions under which these paths may be used (i.e.: biarch packages
must not use these paths), to ensure forward-compatibility with multiarch as
it's deployed.

I'm aware of only one package in the archive that's buggy with this change
in Policy, wine-unstable, which currently (in unstable) has amd64 packages
installing libraries to /usr/lib/i486-linux-gnu/; however, this package is
already violating Policy at present and is using these directories in a
manner inconsistent with the overall plan for multiarch and without
coordination.  I plan to file a serious bug against that package, pending
the outcome of discussion on this bug report.

The content of this particular change can also probably use refining - in
particular, we may wish to spell out use of /usr/lib/<triplet>/<package>
subdirs and /usr/include/<triplet> - but I thought it would be worth getting
feedback on this preliminary patch first.

---
 policy.sgml |   29 +++++++++++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/policy.sgml b/policy.sgml
index 0bf8253..9a28f5f 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -5584,6 +5584,35 @@ libbar 1 bar1 (>= 1.0-1)
               </item>
               <item>
                 <p>
+                  The requirement for libraries, including
+                  <file>libc.so.*</file>, to be located directly under
+                  <file>/lib{,32}</file> and <file>/usr/lib{,32}</file> is
+                  amended, permitting libraries to instead be installed to
+                  <file>/lib/<var>triplet</var></file> and
+                  <file>/usr/lib/<var>triplet</var></file>, where
+                  <tt><var>triplet</var></tt> is the value returned by
+                  <tt>dpkg-architecture -qDEB_HOST_GNU_TYPE</tt> for the
+                  architecture of the package.  Packages may <em>not</em>
+                  install libraries to any <var>triplet</var> path other
+                  than the one matching the architecture of that package;
+                  for instance, an <tt>Architecture: amd64</tt> package
+                  containing 32-bit x86 libraries may not install these
+                  libraries to <file>/usr/lib/i486-linux-gnu</file>.
+                  <footnote>
+                    This is necessary in order to reserve the directories for
+                    use in cross-installation of library packages from other
+                    architectures, as part of the planned deployment of
+                    <tt>multiarch</tt>.
+                  </footnote>
+                </p>
+                <p>
+                  The execution time linker/loader, ld*, must still be made
+                  available in the existing location under /lib or /lib64
+                  since this is part of the ELF ABI for the architecture.
+                </p>
+              </item>
+              <item>
+                <p>
                   The requirement that
                   <file>/usr/local/share/man</file> be "synonymous"
                   with <file>/usr/local/man</file> is relaxed to a
-- 
1.6.3.1


Thanks,
-- 
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@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#542865; Package debian-policy. (Fri, 21 Aug 2009 22:51:16 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>. (Fri, 21 Aug 2009 22:51:16 GMT) Full text and rfc822 format available.

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

From: Russ Allbery <rra@debian.org>
To: 542865@bugs.debian.org
Subject: Re: Bug#542865: Grant an FHS exception for the multiarch library directories
Date: Fri, 21 Aug 2009 15:47:24 -0700
Steve Langasek <vorlon@debian.org> writes:

> The content of this particular change can also probably use refining -
> in particular, we may wish to spell out use of
> /usr/lib/<triplet>/<package> subdirs and /usr/include/<triplet> - but I
> thought it would be worth getting feedback on this preliminary patch
> first.

It looks good to me as a first step.  Seconded, with the caveat that we
probably don't want to release this with Policy until we've hammered out
any specific restrictions on how those directories can be used first.

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




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#542865; Package debian-policy. (Fri, 21 Aug 2009 23:09:13 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Fri, 21 Aug 2009 23:09:14 GMT) Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@debian.org>
To: Russ Allbery <rra@debian.org>, 542865@bugs.debian.org
Subject: Re: Bug#542865: Grant an FHS exception for the multiarch library directories
Date: Fri, 21 Aug 2009 16:00:32 -0700
On Fri, Aug 21, 2009 at 03:47:24PM -0700, Russ Allbery wrote:
> Steve Langasek <vorlon@debian.org> writes:

> > The content of this particular change can also probably use refining -
> > in particular, we may wish to spell out use of
> > /usr/lib/<triplet>/<package> subdirs and /usr/include/<triplet> - but I
> > thought it would be worth getting feedback on this preliminary patch
> > first.

> It looks good to me as a first step.  Seconded, with the caveat that we
> probably don't want to release this with Policy until we've hammered out
> any specific restrictions on how those directories can be used first.

I think the only specific restriction needed is already spelled out - that
packages can only install to the triplet matching their own architecture.
Are there other restrictions that you think are called for?

-- 
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@ubuntu.com                                     vorlon@debian.org




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#542865; Package debian-policy. (Fri, 21 Aug 2009 23:21:05 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>. (Fri, 21 Aug 2009 23:21:05 GMT) Full text and rfc822 format available.

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

From: Russ Allbery <rra@debian.org>
To: Steve Langasek <vorlon@debian.org>
Cc: 542865@bugs.debian.org
Subject: Re: Bug#542865: Grant an FHS exception for the multiarch library directories
Date: Fri, 21 Aug 2009 16:09:57 -0700
Steve Langasek <vorlon@debian.org> writes:
> On Fri, Aug 21, 2009 at 03:47:24PM -0700, Russ Allbery wrote:

>> It looks good to me as a first step.  Seconded, with the caveat that we
>> probably don't want to release this with Policy until we've hammered
>> out any specific restrictions on how those directories can be used
>> first.

> I think the only specific restriction needed is already spelled out -
> that packages can only install to the triplet matching their own
> architecture.  Are there other restrictions that you think are called
> for?

The current restriction is specific to libraries.  Don't we need to say
that you can't put *any* files into any triplet directory that isn't for
your package architecture?

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




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#542865; Package debian-policy. (Sat, 22 Aug 2009 04:36: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, 22 Aug 2009 04:36:03 GMT) Full text and rfc822 format available.

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

From: Russ Allbery <rra@debian.org>
To: 542865@bugs.debian.org
Subject: Re: Bug#542865: Grant an FHS exception for the multiarch library directories
Date: Fri, 21 Aug 2009 21:25:30 -0700
Manoj Srivastava <srivasta@debian.org> writes:
> On Fri, Aug 21 2009, Russ Allbery wrote:

>> The current restriction is specific to libraries.  Don't we need to say
>> that you can't put *any* files into any triplet directory that isn't
>> for your package architecture?

>         Hmm. My first read was that one could not put anything that was
>  not a library in these directories, but perhaps it should be stated
>  explicitly.

I was expecting that we'd need to put anything that you might want to have
simultaneous installs from multiple architectures in that directory, which
would include, for instance, any shared library plugins or loadable
modules, which aren't strictly libraries.

We might have to duplicate some library helper programs as well, if for
instance they communicate with the library using binary structures that
are sensitive to sizeof(long).

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




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#542865; Package debian-policy. (Sat, 22 Aug 2009 08:33:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Bernhard R. Link" <brlink@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 22 Aug 2009 08:33:04 GMT) Full text and rfc822 format available.

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

From: "Bernhard R. Link" <brlink@debian.org>
To: Steve Langasek <vorlon@debian.org>
Cc: 542865@bugs.debian.org
Subject: Re: Bug#542865: Grant an FHS exception for the multiarch library directories
Date: Sat, 22 Aug 2009 10:29:57 +0200
* Steve Langasek <vorlon@debian.org> [090821 23:56]:
> We are approaching the point at which it will be useful to begin having
> packages in the archive that install to the multiarch library paths
> ({/usr,}/lib/<triplet>), for use with the multiarch-capable package manager
> that's in progress.  However, installing libraries to these paths instead of
> directly under {/usr,}/lib is an FHS violation and therefore is currently a
> Policy violation as well.

What are the chances that exactly those directories will end up in future FHS
versions? I could not find anything indicating any coordination on that
on fhs lists. Is there some coordination somewhere else?

Bitten by every second release changing where sparc64 stuff is at the
sparc platform and almost each of those transitions breaking my systems
in some way, I'd prefer if everything possible is done to avoid
changing it again with the next or next but one release again.

Hochachtungsvoll,
	Bernhard R. Link
-- 
"Never contain programs so few bugs, as when no debugging tools are available!"
	Niklaus Wirth




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

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 22 Aug 2009 20:09:03 GMT) Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@debian.org>
To: "Bernhard R. Link" <brlink@debian.org>, 542865@bugs.debian.org
Subject: Re: Bug#542865: Grant an FHS exception for the multiarch library directories
Date: Sat, 22 Aug 2009 13:00:59 -0700
[Message part 1 (text/plain, inline)]
On Sat, Aug 22, 2009 at 10:29:57AM +0200, Bernhard R. Link wrote:
> * Steve Langasek <vorlon@debian.org> [090821 23:56]:
> > We are approaching the point at which it will be useful to begin having
> > packages in the archive that install to the multiarch library paths
> > ({/usr,}/lib/<triplet>), for use with the multiarch-capable package manager
> > that's in progress.  However, installing libraries to these paths instead of
> > directly under {/usr,}/lib is an FHS violation and therefore is currently a
> > Policy violation as well.

> What are the chances that exactly those directories will end up in future
> FHS versions?

Why do you want me to speculate on the *chances* of its inclusion?  I intend
to propose it for inclusion in the FHS once we have an implementation in
Debian; my understanding of the FHS is that they only incorporate things
into the standard for which there's a deployed implementation.

> Bitten by every second release changing where sparc64 stuff is at the
> sparc platform and almost each of those transitions breaking my systems
> in some way, I'd prefer if everything possible is done to avoid
> changing it again with the next or next but one release again.

I frankly have no idea what you're talking about.  I'm not aware that 64-bit
libraries were ever placed anywhere other than [...]/lib64 on sparc, and
in any case multiarch doesn't cause those libraries to stop being used.

-- 
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@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#542865; Package debian-policy. (Sat, 22 Aug 2009 20:21:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 22 Aug 2009 20:21:05 GMT) Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@debian.org>
To: Russ Allbery <rra@debian.org>
Cc: 542865@bugs.debian.org
Subject: Re: Bug#542865: Grant an FHS exception for the multiarch library directories
Date: Sat, 22 Aug 2009 13:11:00 -0700
[Message part 1 (text/plain, inline)]
On Fri, Aug 21, 2009 at 04:09:57PM -0700, Russ Allbery wrote:

> > I think the only specific restriction needed is already spelled out -
> > that packages can only install to the triplet matching their own
> > architecture.  Are there other restrictions that you think are called
> > for?

> The current restriction is specific to libraries.  Don't we need to say
> that you can't put *any* files into any triplet directory that isn't for
> your package architecture?

Yes, good point.  Patch amended.  (Just a one-word change,
s/libraries/files/.)

---
 policy.sgml |   29 +++++++++++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/policy.sgml b/policy.sgml
index 0bf8253..100917d 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -5584,6 +5584,35 @@ libbar 1 bar1 (>= 1.0-1)
               </item>
               <item>
                 <p>
+                  The requirement for libraries, including
+                  <file>libc.so.*</file>, to be located directly under
+                  <file>/lib{,32}</file> and <file>/usr/lib{,32}</file> is
+                  amended, permitting libraries to instead be installed to
+                  <file>/lib/<var>triplet</var></file> and
+                  <file>/usr/lib/<var>triplet</var></file>, where
+                  <tt><var>triplet</var></tt> is the value returned by
+                  <tt>dpkg-architecture -qDEB_HOST_GNU_TYPE</tt> for the
+                  architecture of the package.  Packages may <em>not</em>
+                  install files to any <var>triplet</var> path other
+                  than the one matching the architecture of that package;
+                  for instance, an <tt>Architecture: amd64</tt> package
+                  containing 32-bit x86 libraries may not install these
+                  libraries to <file>/usr/lib/i486-linux-gnu</file>.
+                  <footnote>
+                    This is necessary in order to reserve the directories for
+                    use in cross-installation of library packages from other
+                    architectures, as part of the planned deployment of
+                    <tt>multiarch</tt>.
+                  </footnote>
+                </p>
+                <p>
+                  The execution time linker/loader, ld*, must still be made
+                  available in the existing location under /lib or /lib64
+                  since this is part of the ELF ABI for the architecture.
+                </p>
+              </item>
+              <item>
+                <p>
                   The requirement that
                   <file>/usr/local/share/man</file> be "synonymous"
                   with <file>/usr/local/man</file> is relaxed to a
-- 
1.6.3.1


-- 
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@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#542865; Package debian-policy. (Sat, 22 Aug 2009 20:27:10 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, 22 Aug 2009 20:27:10 GMT) Full text and rfc822 format available.

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

From: Russ Allbery <rra@debian.org>
To: 542865@bugs.debian.org
Subject: Re: Bug#542865: Grant an FHS exception for the multiarch library directories
Date: Sat, 22 Aug 2009 13:16:47 -0700
Looks fine to me.  Seconded.

Steve Langasek <vorlon@debian.org> writes:

> diff --git a/policy.sgml b/policy.sgml
> index 0bf8253..100917d 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -5584,6 +5584,35 @@ libbar 1 bar1 (>= 1.0-1)
>                </item>
>                <item>
>                  <p>
> +                  The requirement for libraries, including
> +                  <file>libc.so.*</file>, to be located directly under
> +                  <file>/lib{,32}</file> and <file>/usr/lib{,32}</file> is
> +                  amended, permitting libraries to instead be installed to
> +                  <file>/lib/<var>triplet</var></file> and
> +                  <file>/usr/lib/<var>triplet</var></file>, where
> +                  <tt><var>triplet</var></tt> is the value returned by
> +                  <tt>dpkg-architecture -qDEB_HOST_GNU_TYPE</tt> for the
> +                  architecture of the package.  Packages may <em>not</em>
> +                  install files to any <var>triplet</var> path other
> +                  than the one matching the architecture of that package;
> +                  for instance, an <tt>Architecture: amd64</tt> package
> +                  containing 32-bit x86 libraries may not install these
> +                  libraries to <file>/usr/lib/i486-linux-gnu</file>.
> +                  <footnote>
> +                    This is necessary in order to reserve the directories for
> +                    use in cross-installation of library packages from other
> +                    architectures, as part of the planned deployment of
> +                    <tt>multiarch</tt>.
> +                  </footnote>
> +                </p>
> +                <p>
> +                  The execution time linker/loader, ld*, must still be made
> +                  available in the existing location under /lib or /lib64
> +                  since this is part of the ELF ABI for the architecture.
> +                </p>
> +              </item>
> +              <item>
> +                <p>
>                    The requirement that
>                    <file>/usr/local/share/man</file> be "synonymous"
>                    with <file>/usr/local/man</file> is relaxed to a

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




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#542865; Package debian-policy. (Sat, 22 Aug 2009 23:06:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kurt Roeckx <kurt@roeckx.be>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 22 Aug 2009 23:06:02 GMT) Full text and rfc822 format available.

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

From: Kurt Roeckx <kurt@roeckx.be>
To: Steve Langasek <vorlon@debian.org>, 542865@bugs.debian.org
Cc: Russ Allbery <rra@debian.org>
Subject: Re: Bug#542865: Grant an FHS exception for the multiarch library directories
Date: Sun, 23 Aug 2009 01:02:10 +0200
[Message part 1 (text/plain, inline)]
On Sat, Aug 22, 2009 at 01:11:00PM -0700, Steve Langasek wrote:
> On Fri, Aug 21, 2009 at 04:09:57PM -0700, Russ Allbery wrote:
> 
> > > I think the only specific restriction needed is already spelled out -
> > > that packages can only install to the triplet matching their own
> > > architecture.  Are there other restrictions that you think are called
> > > for?
> 
> > The current restriction is specific to libraries.  Don't we need to say
> > that you can't put *any* files into any triplet directory that isn't for
> > your package architecture?
> 
> Yes, good point.  Patch amended.  (Just a one-word change,
> s/libraries/files/.)

Seconded.

But I wonder if it should also mention /lib64 and /usr/lib64,
since they are also in FHS and actually the path's amd64
is supposed to use according to the FHS.


Kurt

> 
> ---
>  policy.sgml |   29 +++++++++++++++++++++++++++++
>  1 files changed, 29 insertions(+), 0 deletions(-)
> 
> diff --git a/policy.sgml b/policy.sgml
> index 0bf8253..100917d 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -5584,6 +5584,35 @@ libbar 1 bar1 (>= 1.0-1)
>                </item>
>                <item>
>                  <p>
> +                  The requirement for libraries, including
> +                  <file>libc.so.*</file>, to be located directly under
> +                  <file>/lib{,32}</file> and <file>/usr/lib{,32}</file> is
> +                  amended, permitting libraries to instead be installed to
> +                  <file>/lib/<var>triplet</var></file> and
> +                  <file>/usr/lib/<var>triplet</var></file>, where
> +                  <tt><var>triplet</var></tt> is the value returned by
> +                  <tt>dpkg-architecture -qDEB_HOST_GNU_TYPE</tt> for the
> +                  architecture of the package.  Packages may <em>not</em>
> +                  install files to any <var>triplet</var> path other
> +                  than the one matching the architecture of that package;
> +                  for instance, an <tt>Architecture: amd64</tt> package
> +                  containing 32-bit x86 libraries may not install these
> +                  libraries to <file>/usr/lib/i486-linux-gnu</file>.
> +                  <footnote>
> +                    This is necessary in order to reserve the directories for
> +                    use in cross-installation of library packages from other
> +                    architectures, as part of the planned deployment of
> +                    <tt>multiarch</tt>.
> +                  </footnote>
> +                </p>
> +                <p>
> +                  The execution time linker/loader, ld*, must still be made
> +                  available in the existing location under /lib or /lib64
> +                  since this is part of the ELF ABI for the architecture.
> +                </p>
> +              </item>
> +              <item>
> +                <p>
>                    The requirement that
>                    <file>/usr/local/share/man</file> be "synonymous"
>                    with <file>/usr/local/man</file> is relaxed to a
> -- 
> 1.6.3.1
> 
> 
> -- 
> 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@ubuntu.com                                     vorlon@debian.org


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

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#542865; Package debian-policy. (Sat, 22 Aug 2009 23:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 22 Aug 2009 23:30:03 GMT) Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@debian.org>
To: Kurt Roeckx <kurt@roeckx.be>, 542865@bugs.debian.org
Cc: Russ Allbery <rra@debian.org>
Subject: Re: Bug#542865: Grant an FHS exception for the multiarch library directories
Date: Sat, 22 Aug 2009 16:27:34 -0700
[Message part 1 (text/plain, inline)]
On Sun, Aug 23, 2009 at 01:02:10AM +0200, Kurt Roeckx wrote:
> Seconded.

> But I wonder if it should also mention /lib64 and /usr/lib64,
> since they are also in FHS and actually the path's amd64
> is supposed to use according to the FHS.

Policy already has an exception for /lib64.

-- 
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@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#542865; Package debian-policy. (Sun, 23 Aug 2009 07:55:43 GMT) Full text and rfc822 format available.

Acknowledgement sent to Julien Cristau <jcristau@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 23 Aug 2009 07:55:43 GMT) Full text and rfc822 format available.

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

From: Julien Cristau <jcristau@debian.org>
To: Steve Langasek <vorlon@debian.org>, 542865@bugs.debian.org
Subject: Re: Bug#542865: Grant an FHS exception for the multiarch library directories
Date: Sun, 23 Aug 2009 09:35:57 +0200
On Sat, Aug 22, 2009 at 13:11:00 -0700, Steve Langasek wrote:

> diff --git a/policy.sgml b/policy.sgml
> index 0bf8253..100917d 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -5584,6 +5584,35 @@ libbar 1 bar1 (>= 1.0-1)
>                </item>
>                <item>
>                  <p>
> +                  The requirement for libraries, including
> +                  <file>libc.so.*</file>, to be located directly under
> +                  <file>/lib{,32}</file> and <file>/usr/lib{,32}</file> is
> +                  amended, permitting libraries to instead be installed to
> +                  <file>/lib/<var>triplet</var></file> and
> +                  <file>/usr/lib/<var>triplet</var></file>, where
> +                  <tt><var>triplet</var></tt> is the value returned by
> +                  <tt>dpkg-architecture -qDEB_HOST_GNU_TYPE</tt> for the
> +                  architecture of the package.  Packages may <em>not</em>
> +                  install files to any <var>triplet</var> path other
> +                  than the one matching the architecture of that package;
> +                  for instance, an <tt>Architecture: amd64</tt> package
> +                  containing 32-bit x86 libraries may not install these
> +                  libraries to <file>/usr/lib/i486-linux-gnu</file>.
> +                  <footnote>
> +                    This is necessary in order to reserve the directories for
> +                    use in cross-installation of library packages from other
> +                    architectures, as part of the planned deployment of
> +                    <tt>multiarch</tt>.
> +                  </footnote>
> +                </p>
> +                <p>
> +                  The execution time linker/loader, ld*, must still be made
> +                  available in the existing location under /lib or /lib64
> +                  since this is part of the ELF ABI for the architecture.
> +                </p>
> +              </item>
> +              <item>
> +                <p>
>                    The requirement that
>                    <file>/usr/local/share/man</file> be "synonymous"
>                    with <file>/usr/local/man</file> is relaxed to a

Seconded.

Cheers,
Julien




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#542865; Package debian-policy. (Sun, 23 Aug 2009 11:36:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Bernhard R. Link" <brlink@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 23 Aug 2009 11:36:09 GMT) Full text and rfc822 format available.

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

From: "Bernhard R. Link" <brlink@debian.org>
To: Steve Langasek <vorlon@debian.org>
Cc: 542865@bugs.debian.org
Subject: Re: Bug#542865: Grant an FHS exception for the multiarch library directories
Date: Sun, 23 Aug 2009 12:57:07 +0200
* Steve Langasek <vorlon@debian.org> [090822 22:11]:
> > What are the chances that exactly those directories will end up in future
> > FHS versions?
>
> Why do you want me to speculate on the *chances* of its inclusion?

Preferably I'd like some arguments that ther is a high chance of its
inclusion.

> my understanding of the FHS is that they only incorporate things
> into the standard for which there's a deployed implementation.

That's my understanding, too. I'm not asking to delay this until it is
in FHS. All I want to know if this is some isolated "let's try this
and tell noone about and if we are fast enough the others might follow"
or if it is some "We spoke with some others and they see no problem with
this scheme and will follow and put in FHS if that works for us".

> > Bitten by every second release changing where sparc64 stuff is at the
> > sparc platform and almost each of those transitions breaking my systems
> > in some way, I'd prefer if everything possible is done to avoid
> > changing it again with the next or next but one release again.
>
> I frankly have no idea what you're talking about.  I'm not aware that 64-bit
> libraries were ever placed anywhere other than [...]/lib64 on sparc,

For example take a look at woody:

|>dpkg-deb -c fakeroot_0.4.4-9.2_sparc.deb  | grep 64
|drwxr-xr-x root/root         0 2001-05-12 05:51 ./usr/lib/64/
|drwxr-xr-x root/root         0 2001-05-12 05:51 ./usr/lib/64/libfakeroot/
|-rw-r--r-- root/root     24552 2001-05-12 05:51 ./usr/lib/64/libfakeroot/libfakeroot.so.0.0.1
|lrwxrwxrwx root/root         0 2001-05-12 05:51 ./usr/lib/64/libfakeroot/libfakeroot.so.0 -> libfakeroot.so.0.0.1
|lrwxrwxrwx root/root         0 2001-05-12 05:51 ./usr/lib/64/libfakeroot/libfakeroot.so -> libfakeroot.so.0.0.1

|>dpkg-deb -c libc6-sparc64_2.2.5-11.8_sparc.deb | grep \/64
|lrwxrwxrwx root/root         0 2005-01-07 17:49 ./usr/lib/64 -> ../lib64
|lrwxrwxrwx root/root         0 2005-01-07 17:49 ./lib/64 -> ../lib64

I can guess you can imagine what happend when upgrading in half of the cases...

Hochachtungsvoll,
	Bernhard R. Link




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#542865; Package debian-policy. (Sun, 23 Aug 2009 19:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sun, 23 Aug 2009 19:48:04 GMT) Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@debian.org>
To: "Bernhard R. Link" <brlink@debian.org>
Cc: 542865@bugs.debian.org
Subject: Re: Bug#542865: Grant an FHS exception for the multiarch library directories
Date: Sun, 23 Aug 2009 12:39:25 -0700
[Message part 1 (text/plain, inline)]
On Sun, Aug 23, 2009 at 12:57:07PM +0200, Bernhard R. Link wrote:
> > > Bitten by every second release changing where sparc64 stuff is at the
> > > sparc platform and almost each of those transitions breaking my systems
> > > in some way, I'd prefer if everything possible is done to avoid
> > > changing it again with the next or next but one release again.

> > I frankly have no idea what you're talking about.  I'm not aware that 64-bit
> > libraries were ever placed anywhere other than [...]/lib64 on sparc,

> For example take a look at woody:

> |>dpkg-deb -c fakeroot_0.4.4-9.2_sparc.deb  | grep 64
> |drwxr-xr-x root/root         0 2001-05-12 05:51 ./usr/lib/64/
> |drwxr-xr-x root/root         0 2001-05-12 05:51 ./usr/lib/64/libfakeroot/
> |-rw-r--r-- root/root     24552 2001-05-12 05:51 ./usr/lib/64/libfakeroot/libfakeroot.so.0.0.1
> |lrwxrwxrwx root/root         0 2001-05-12 05:51 ./usr/lib/64/libfakeroot/libfakeroot.so.0 -> libfakeroot.so.0.0.1
> |lrwxrwxrwx root/root         0 2001-05-12 05:51 ./usr/lib/64/libfakeroot/libfakeroot.so -> libfakeroot.so.0.0.1

> |>dpkg-deb -c libc6-sparc64_2.2.5-11.8_sparc.deb | grep \/64
> |lrwxrwxrwx root/root         0 2005-01-07 17:49 ./usr/lib/64 -> ../lib64
> |lrwxrwxrwx root/root         0 2005-01-07 17:49 ./lib/64 -> ../lib64

> I can guess you can imagine what happend when upgrading in half of the cases...

Oh; so "every second release" -> "one release, 7 years ago, in which there
was a bug".

-- 
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@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#542865; Package debian-policy. (Mon, 24 Aug 2009 09:06:11 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Bernhard R. Link" <brlink@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Mon, 24 Aug 2009 09:06:11 GMT) Full text and rfc822 format available.

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

From: "Bernhard R. Link" <brlink@debian.org>
To: Steve Langasek <vorlon@debian.org>
Cc: 542865@bugs.debian.org
Subject: Re: Bug#542865: Grant an FHS exception for the multiarch library directories
Date: Mon, 24 Aug 2009 10:29:25 +0200
* Steve Langasek <vorlon@debian.org> [090823 21:51]:
> Oh; so "every second release" -> "one release, 7 years ago, in which there
> was a bug".

Thanks that you point out my mistake in so nice terms. I'm pleading
guilty of the high crime of doing an estimation and erring by 100%
(25% of all releases with sparc64 libc I can show evidence of brokeness
while "every second" of course can only mean exactly "50%").

Now that you have successfully attacked my reputation, could we return
to the point of my actual question:

Do I conclude correctly that there is no coordination with other
distributions at all for this chance and you have no idea if those paths
will be the final or need some transition (which of course will be no
problem unless someone adds some of those nasty "bugs" again).

Or are there any facts that would appease my mind that you did not give
because I would not understand them anyway being so ridiculous as I am?

Thanks in advance,
	Bernhard R. Link




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#542865; Package debian-policy. (Sat, 05 Sep 2009 03:54:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Sat, 05 Sep 2009 03:54:02 GMT) Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@debian.org>
To: Russ Allbery <rra@debian.org>, 542865@bugs.debian.org
Subject: Re: Bug#542865: Grant an FHS exception for the multiarch library directories
Date: Fri, 4 Sep 2009 20:50:30 -0700
[Message part 1 (text/plain, inline)]
On Fri, Aug 21, 2009 at 09:25:30PM -0700, Russ Allbery wrote:
> Manoj Srivastava <srivasta@debian.org> writes:
> > On Fri, Aug 21 2009, Russ Allbery wrote:

> >> The current restriction is specific to libraries.  Don't we need to say
> >> that you can't put *any* files into any triplet directory that isn't
> >> for your package architecture?

> >         Hmm. My first read was that one could not put anything that was
> >  not a library in these directories, but perhaps it should be stated
> >  explicitly.

> I was expecting that we'd need to put anything that you might want to have
> simultaneous installs from multiple architectures in that directory, which
> would include, for instance, any shared library plugins or loadable
> modules, which aren't strictly libraries.

> We might have to duplicate some library helper programs as well, if for
> instance they communicate with the library using binary structures that
> are sensitive to sizeof(long).

Right, this was a bug in the proposed patch, not a deliberate statement that
only libraries belong in these directories.  (As I mentioned, the first
patch was something of a trial balloon.)  I think this updated patch should
cover everything for the first round.

Re-seconds?

---
 policy.sgml |   34 ++++++++++++++++++++++++++++++++++
 1 files changed, 34 insertions(+), 0 deletions(-)

diff --git a/policy.sgml b/policy.sgml
index 0bf8253..347c0bf 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -5584,6 +5584,40 @@ libbar 1 bar1 (>= 1.0-1)
               </item>
               <item>
                 <p>
+                  The requirement for object files, internal binaries, and
+                  libraries, including <file>libc.so.*</file>, to be located
+                  directly under <file>/lib{,32}</file> and
+                  <file>/usr/lib{,32}</file> is amended, permitting files
+                  to instead be installed to
+                  <file>/lib/<var>triplet</var></file> and
+                  <file>/usr/lib/<var>triplet</var></file>, where
+                  <tt><var>triplet</var></tt> is the value returned by
+                  <tt>dpkg-architecture -qDEB_HOST_GNU_TYPE</tt> for the
+                  architecture of the package.  Packages may <em>not</em>
+                  install files to any <var>triplet</var> path other
+                  than the one matching the architecture of that package;
+                  for instance, an <tt>Architecture: amd64</tt> package
+                  containing 32-bit x86 libraries may not install these
+                  libraries to <file>/usr/lib/i486-linux-gnu</file>.
+                  <footnote>
+                    This is necessary in order to reserve the directories for
+                    use in cross-installation of library packages from other
+                    architectures, as part of the planned deployment of
+                    <tt>multiarch</tt>.
+                  </footnote>
+                </p>
+                <p>
+                  Applications may also use a single subdirectory under
+                  <file>/usr/lib/<var>triplet</var></file>.
+                </p>
+                <p>
+                  The execution time linker/loader, ld*, must still be made
+                  available in the existing location under /lib or /lib64
+                  since this is part of the ELF ABI for the architecture.
+                </p>
+              </item>
+              <item>
+                <p>
                   The requirement that
                   <file>/usr/local/share/man</file> be "synonymous"
                   with <file>/usr/local/man</file> is relaxed to a
-- 
1.6.3.3

Thanks,
-- 
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@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Severity set to 'wishlist' from 'normal' Request was from Manoj Srivastava <srivasta@debian.org> to control@bugs.debian.org. (Mon, 07 Sep 2009 21:00:11 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#542865; Package debian-policy. (Tue, 08 Sep 2009 07:45:31 GMT) Full text and rfc822 format available.

Acknowledgement sent to Aurelien Jarno <aurelien@aurel32.net>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Tue, 08 Sep 2009 07:45:32 GMT) Full text and rfc822 format available.

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

From: Aurelien Jarno <aurelien@aurel32.net>
To: Steve Langasek <vorlon@debian.org>
Cc: 542865@bugs.debian.org
Subject: Re: Bug#542865: Grant an FHS exception for the multiarch library directories
Date: Tue, 8 Sep 2009 09:35:21 +0200
[Message part 1 (text/plain, inline)]
On Fri, Sep 04, 2009 at 08:50:30PM -0700, Steve Langasek wrote:
> On Fri, Aug 21, 2009 at 09:25:30PM -0700, Russ Allbery wrote:
> > Manoj Srivastava <srivasta@debian.org> writes:
> > > On Fri, Aug 21 2009, Russ Allbery wrote:
> 
> > >> The current restriction is specific to libraries.  Don't we need to say
> > >> that you can't put *any* files into any triplet directory that isn't
> > >> for your package architecture?
> 
> > >         Hmm. My first read was that one could not put anything that was
> > >  not a library in these directories, but perhaps it should be stated
> > >  explicitly.
> 
> > I was expecting that we'd need to put anything that you might want to have
> > simultaneous installs from multiple architectures in that directory, which
> > would include, for instance, any shared library plugins or loadable
> > modules, which aren't strictly libraries.
> 
> > We might have to duplicate some library helper programs as well, if for
> > instance they communicate with the library using binary structures that
> > are sensitive to sizeof(long).
> 
> Right, this was a bug in the proposed patch, not a deliberate statement that
> only libraries belong in these directories.  (As I mentioned, the first
> patch was something of a trial balloon.)  I think this updated patch should
> cover everything for the first round.
> 
> Re-seconds?

Seconded.

> ---
>  policy.sgml |   34 ++++++++++++++++++++++++++++++++++
>  1 files changed, 34 insertions(+), 0 deletions(-)
> 
> diff --git a/policy.sgml b/policy.sgml
> index 0bf8253..347c0bf 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -5584,6 +5584,40 @@ libbar 1 bar1 (>= 1.0-1)
>                </item>
>                <item>
>                  <p>
> +                  The requirement for object files, internal binaries, and
> +                  libraries, including <file>libc.so.*</file>, to be located
> +                  directly under <file>/lib{,32}</file> and
> +                  <file>/usr/lib{,32}</file> is amended, permitting files
> +                  to instead be installed to
> +                  <file>/lib/<var>triplet</var></file> and
> +                  <file>/usr/lib/<var>triplet</var></file>, where
> +                  <tt><var>triplet</var></tt> is the value returned by
> +                  <tt>dpkg-architecture -qDEB_HOST_GNU_TYPE</tt> for the
> +                  architecture of the package.  Packages may <em>not</em>
> +                  install files to any <var>triplet</var> path other
> +                  than the one matching the architecture of that package;
> +                  for instance, an <tt>Architecture: amd64</tt> package
> +                  containing 32-bit x86 libraries may not install these
> +                  libraries to <file>/usr/lib/i486-linux-gnu</file>.
> +                  <footnote>
> +                    This is necessary in order to reserve the directories for
> +                    use in cross-installation of library packages from other
> +                    architectures, as part of the planned deployment of
> +                    <tt>multiarch</tt>.
> +                  </footnote>
> +                </p>
> +                <p>
> +                  Applications may also use a single subdirectory under
> +                  <file>/usr/lib/<var>triplet</var></file>.
> +                </p>
> +                <p>
> +                  The execution time linker/loader, ld*, must still be made
> +                  available in the existing location under /lib or /lib64
> +                  since this is part of the ELF ABI for the architecture.
> +                </p>
> +              </item>
> +              <item>
> +                <p>
>                    The requirement that
>                    <file>/usr/local/share/man</file> be "synonymous"
>                    with <file>/usr/local/man</file> is relaxed to a
> -- 
> 1.6.3.3
> 
> Thanks,
> -- 
> 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@ubuntu.com                                     vorlon@debian.org



-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#542865; Package debian-policy. (Tue, 08 Sep 2009 09:37:41 GMT) Full text and rfc822 format available.

Acknowledgement sent to Julien Cristau <jcristau@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Tue, 08 Sep 2009 09:37:45 GMT) Full text and rfc822 format available.

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

From: Julien Cristau <jcristau@debian.org>
To: Steve Langasek <vorlon@debian.org>, 542865@bugs.debian.org
Cc: Russ Allbery <rra@debian.org>
Subject: Re: Bug#542865: Grant an FHS exception for the multiarch library directories
Date: Tue, 8 Sep 2009 11:36:04 +0200
On Fri, Sep  4, 2009 at 20:50:30 -0700, Steve Langasek wrote:

> +                <p>
> +                  Applications may also use a single subdirectory under
> +                  <file>/usr/lib/<var>triplet</var></file>.
> +                </p>

Is /lib/<triplet> intentionally left out here?  I don't know how likely
that is, but if people want multiarch-compatible pam, it would have to
install modules to /lib/<triplet>/security?

Cheers,
Julien




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#542865; Package debian-policy. (Tue, 08 Sep 2009 10:39:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Steve Langasek <vorlon@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Tue, 08 Sep 2009 10:39:08 GMT) Full text and rfc822 format available.

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

From: Steve Langasek <vorlon@debian.org>
To: Julien Cristau <jcristau@debian.org>
Cc: 542865@bugs.debian.org, Russ Allbery <rra@debian.org>
Subject: Re: Bug#542865: Grant an FHS exception for the multiarch library directories
Date: Tue, 8 Sep 2009 02:52:30 -0700
[Message part 1 (text/plain, inline)]
On Tue, Sep 08, 2009 at 11:36:04AM +0200, Julien Cristau wrote:
> On Fri, Sep  4, 2009 at 20:50:30 -0700, Steve Langasek wrote:

> > +                <p>
> > +                  Applications may also use a single subdirectory under
> > +                  <file>/usr/lib/<var>triplet</var></file>.
> > +                </p>

> Is /lib/<triplet> intentionally left out here?

Yes - the FHS doesn't grant permission to create subdirectories under /lib
currently, and our exception shouldn't go beyond what the FHS specifies.

(Whether this means /lib/security is an FHS violation... you be the judge.
:)

> I don't know how likely that is, but if people want multiarch-compatible
> pam, it would have to install modules to /lib/<triplet>/security?

Yes, the pam multiarch packaging branch that I have here does that. :)

-- 
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@ubuntu.com                                     vorlon@debian.org
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#542865; Package debian-policy. (Tue, 08 Sep 2009 11:30:34 GMT) Full text and rfc822 format available.

Acknowledgement sent to Julien Cristau <jcristau@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Tue, 08 Sep 2009 11:30:34 GMT) Full text and rfc822 format available.

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

From: Julien Cristau <jcristau@debian.org>
To: Steve Langasek <vorlon@debian.org>, 542865@bugs.debian.org
Cc: Russ Allbery <rra@debian.org>
Subject: Re: Bug#542865: Grant an FHS exception for the multiarch library directories
Date: Tue, 8 Sep 2009 12:50:21 +0200
On Fri, Sep  4, 2009 at 20:50:30 -0700, Steve Langasek wrote:

> diff --git a/policy.sgml b/policy.sgml
> index 0bf8253..347c0bf 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -5584,6 +5584,40 @@ libbar 1 bar1 (>= 1.0-1)
>                </item>
>                <item>
>                  <p>
> +                  The requirement for object files, internal binaries, and
> +                  libraries, including <file>libc.so.*</file>, to be located
> +                  directly under <file>/lib{,32}</file> and
> +                  <file>/usr/lib{,32}</file> is amended, permitting files
> +                  to instead be installed to
> +                  <file>/lib/<var>triplet</var></file> and
> +                  <file>/usr/lib/<var>triplet</var></file>, where
> +                  <tt><var>triplet</var></tt> is the value returned by
> +                  <tt>dpkg-architecture -qDEB_HOST_GNU_TYPE</tt> for the
> +                  architecture of the package.  Packages may <em>not</em>
> +                  install files to any <var>triplet</var> path other
> +                  than the one matching the architecture of that package;
> +                  for instance, an <tt>Architecture: amd64</tt> package
> +                  containing 32-bit x86 libraries may not install these
> +                  libraries to <file>/usr/lib/i486-linux-gnu</file>.
> +                  <footnote>
> +                    This is necessary in order to reserve the directories for
> +                    use in cross-installation of library packages from other
> +                    architectures, as part of the planned deployment of
> +                    <tt>multiarch</tt>.
> +                  </footnote>
> +                </p>
> +                <p>
> +                  Applications may also use a single subdirectory under
> +                  <file>/usr/lib/<var>triplet</var></file>.
> +                </p>
> +                <p>
> +                  The execution time linker/loader, ld*, must still be made
> +                  available in the existing location under /lib or /lib64
> +                  since this is part of the ELF ABI for the architecture.
> +                </p>
> +              </item>
> +              <item>
> +                <p>
>                    The requirement that
>                    <file>/usr/local/share/man</file> be "synonymous"
>                    with <file>/usr/local/man</file> is relaxed to a

Seconded (again).

Cheers,
Julien




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Policy List <debian-policy@lists.debian.org>:
Bug#542865; Package debian-policy. (Wed, 09 Sep 2009 18:03:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Kurt Roeckx <kurt@roeckx.be>:
Extra info received and forwarded to list. Copy sent to Debian Policy List <debian-policy@lists.debian.org>. (Wed, 09 Sep 2009 18:03:04 GMT) Full text and rfc822 format available.

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

From: Kurt Roeckx <kurt@roeckx.be>
To: Steve Langasek <vorlon@debian.org>, 542865@bugs.debian.org
Cc: Russ Allbery <rra@debian.org>
Subject: Re: Bug#542865: Grant an FHS exception for the multiarch library directories
Date: Wed, 9 Sep 2009 19:51:05 +0200
[Message part 1 (text/plain, inline)]
On Fri, Sep 04, 2009 at 08:50:30PM -0700, Steve Langasek wrote:
> 
> Right, this was a bug in the proposed patch, not a deliberate statement that
> only libraries belong in these directories.  (As I mentioned, the first
> patch was something of a trial balloon.)  I think this updated patch should
> cover everything for the first round.
> 
> Re-seconds?
> 
> ---
>  policy.sgml |   34 ++++++++++++++++++++++++++++++++++
>  1 files changed, 34 insertions(+), 0 deletions(-)
> 
> diff --git a/policy.sgml b/policy.sgml
> index 0bf8253..347c0bf 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -5584,6 +5584,40 @@ libbar 1 bar1 (>= 1.0-1)
>                </item>
>                <item>
>                  <p>
> +                  The requirement for object files, internal binaries, and
> +                  libraries, including <file>libc.so.*</file>, to be located
> +                  directly under <file>/lib{,32}</file> and
> +                  <file>/usr/lib{,32}</file> is amended, permitting files
> +                  to instead be installed to
> +                  <file>/lib/<var>triplet</var></file> and
> +                  <file>/usr/lib/<var>triplet</var></file>, where
> +                  <tt><var>triplet</var></tt> is the value returned by
> +                  <tt>dpkg-architecture -qDEB_HOST_GNU_TYPE</tt> for the
> +                  architecture of the package.  Packages may <em>not</em>
> +                  install files to any <var>triplet</var> path other
> +                  than the one matching the architecture of that package;
> +                  for instance, an <tt>Architecture: amd64</tt> package
> +                  containing 32-bit x86 libraries may not install these
> +                  libraries to <file>/usr/lib/i486-linux-gnu</file>.
> +                  <footnote>
> +                    This is necessary in order to reserve the directories for
> +                    use in cross-installation of library packages from other
> +                    architectures, as part of the planned deployment of
> +                    <tt>multiarch</tt>.
> +                  </footnote>
> +                </p>
> +                <p>
> +                  Applications may also use a single subdirectory under
> +                  <file>/usr/lib/<var>triplet</var></file>.
> +                </p>
> +                <p>
> +                  The execution time linker/loader, ld*, must still be made
> +                  available in the existing location under /lib or /lib64
> +                  since this is part of the ELF ABI for the architecture.
> +                </p>
> +              </item>
> +              <item>
> +                <p>
>                    The requirement that
>                    <file>/usr/local/share/man</file> be "synonymous"
>                    with <file>/usr/local/man</file> is relaxed to a
> -- 
> 1.6.3.3

Seconded.


Kurt

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

Added tag(s) pending. Request was from Manoj Srivastava <srivasta@debian.org> to control@bugs.debian.org. (Wed, 16 Sep 2009 02:03:02 GMT) Full text and rfc822 format available.

Reply sent to Bill Allombert <ballombe@debian.org>:
You have taken responsibility. (Wed, 27 Jan 2010 21:39:07 GMT) Full text and rfc822 format available.

Notification sent to Steve Langasek <vorlon@debian.org>:
Bug acknowledged by developer. (Wed, 27 Jan 2010 21:39:08 GMT) Full text and rfc822 format available.

Message #114 received at 542865-close@bugs.debian.org (full text, mbox):

From: Bill Allombert <ballombe@debian.org>
To: 542865-close@bugs.debian.org
Subject: Bug#542865: fixed in debian-policy 3.8.4.0
Date: Wed, 27 Jan 2010 21:36:19 +0000
Source: debian-policy
Source-Version: 3.8.4.0

We believe that the bug you reported is fixed in the latest version of
debian-policy, which is due to be installed in the Debian FTP archive:

debian-policy_3.8.4.0.dsc
  to main/d/debian-policy/debian-policy_3.8.4.0.dsc
debian-policy_3.8.4.0.tar.gz
  to main/d/debian-policy/debian-policy_3.8.4.0.tar.gz
debian-policy_3.8.4.0_all.deb
  to main/d/debian-policy/debian-policy_3.8.4.0_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 542865@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Bill Allombert <ballombe@debian.org> (supplier of updated debian-policy package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Wed, 27 Jan 2010 19:22:43 +0100
Source: debian-policy
Binary: debian-policy
Architecture: source all
Version: 3.8.4.0
Distribution: unstable
Urgency: low
Maintainer: Debian Policy List <debian-policy@lists.debian.org>
Changed-By: Bill Allombert <ballombe@debian.org>
Description: 
 debian-policy - Debian Policy Manual and related documents
Closes: 391836 518199 542865 544353 545548 550192 552757 556972
Changes: 
 debian-policy (3.8.4.0) unstable; urgency=low
 .
   [ Bill Allombert ]
   * Also provide documents in single-file HTML format.
     Proposed by Jari Aalto.
     Closes: #544353
   * Number the DFSG points like in the social_contract document.
     Proposed by Enrico Zini.
     Closes: #550192
 .
   [ Manoj Srivastava ]
   * [b270d2d]: Typo fix: relayed -> related. Thanks to Matt Kraai for
     pointing this out.
   * [c74ac74]:
     Policy: Grant an FHS exception for the multiarch library directories
     Wording: Steve Langasek.
     Seconded: Aurelien Jarno
     Seconded: Julien Cristau
     Seconded: Kurt Roeckx
     Closes: #542865
   * [7ac3ee6]:
     virtual package list: Added Doom virtual packages
     Wording: Manoj Srivastava
     Seconded: Russ Allbery
     Seconded: Giacomo A. Catenazzi
     Closes: #518199
   * [8fd91a0]
     README Process upgrading-checklist: Created/converted to org-mode
     Wording: Manoj Srivastava
     Seconded: Russ Allbery
     Closes: #545548
   * [4da0692]: [typo-fixes]:
     policy: Fix a number of grammatical or typographical errors
     wording: Eric Dantan Rzewnicki
     Seconded: Manoj Srivastava
   * [112c4bc]: FHS Exceptions
     policy: Explicitly allow /selinux and /sys as FHS exceptions
     Wording: Manoj Srivastava
     Seconded: Russ Allbery <rra@debian.org>
     Seconded: Kurt Roeckx  <kurt@roeckx.be>
     Closes: #556972
     This patch explicitly allows /sys and /selinux as additional
     directories in the root file system allowed under the policy.
   * [16afbcb]: Clarify ./debian/rules #! line
     policy: Clarify rule for debian/rules shebang line
     Wording: Ben Finney <ben+debian@benfinney.id.au>
     Seconded: Kurt Roeckx <kurt@roeckx.be>
     Seconded: Russ Allbery <rra@debian.org>
     Seconded: Manoj Srivastava <srivasta@debian.org>
     Explicitly state that  "make -f debian/rules" and "./debian/rules"
     must behave  identically, to prevent confusion, and to promote
     reproducibility, and conform to the principle of least surprise.
   * [dab93b2]: Add a cron-daemon virtual package
     policy, virtual package list: New virtual package: cron-daemon
     wording: Javier Fernández-Sanguino Peña, Manoj Srivastava
     Seconded: Russ Allbery <rra@debian.org>
     Seconded: Kurt Roeckx  <kurt@roeckx.be>
     Closes: #391836
     Create a virtual cron daemon package that:
      - Has to provide /usr/bin/crontab and support crontab entries
      - Correct execution of /etc/cron.d
      - Correct support of /etc/crontab
      - Support of crontab entries with names for days and months,
        ranges, step values
      - Correct execution of /etc/cron.{hourly,daily,weekly,monthly}
 .
   [ Russ Allbery ]
   * Policy: Clarify policy on named pipes in packages
     Wording: Russ Allbery <rra@debian.org>
     Seconded: Manoj Srivastava <srivasta@debian.org>
     Seconded: Andrew McMillan <andrew@morphoss.com>
   * Change the sole occurrence of MUST to must for consistency and to
     avoid confusion with IETF RFC keywords.  Thanks, Jakub Wilk.
     (Closes: #552757)
Checksums-Sha1: 
 4d3388c03937f68346516b137d4ef9ed470d217f 1195 debian-policy_3.8.4.0.dsc
 0162f8464f3d3d626b2a7b963b6fb1274a85dd44 708812 debian-policy_3.8.4.0.tar.gz
 0ffb595531397b3579e7ffb225e4681a6fca0433 1771588 debian-policy_3.8.4.0_all.deb
Checksums-Sha256: 
 aea026a91870b9f84977a4d0fd98e7d45cc0cf1679549ae4fa3c27977e8eddfa 1195 debian-policy_3.8.4.0.dsc
 6b2dbe5b1af261e55f55c9eb5c52db8723bde1d74e2e85056fdf2fcdc10a0a8a 708812 debian-policy_3.8.4.0.tar.gz
 2b703b9344b01055ae6cac7d51768b80228af82ce5cede9fff03ebf7a43317ca 1771588 debian-policy_3.8.4.0_all.deb
Files: 
 e0c84d5a5aedca4c39112f9d7f18d667 1195 doc optional debian-policy_3.8.4.0.dsc
 6e9670cd589b9ead4ab09f1adcac1830 708812 doc optional debian-policy_3.8.4.0.tar.gz
 1341450fbb9e830f9060ac2d783db3ab 1771588 doc optional debian-policy_3.8.4.0_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAktgoDAACgkQeDPs8bVESBX2gACdFGUcbGLCe05yA4aqyEArJHCW
7vIAn3WxFWVvleWoh9Vhrjx1FiLCyxqg
=kG0f
-----END PGP SIGNATURE-----





Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sun, 07 Mar 2010 07:39:44 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: Thu Apr 24 22:17:08 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.