Bug#630174: debian-policy: forbid installation into /lib64

[Sean Whitton]

control: tag -1 -patch +pending

I too second the following change proposed by Bill:

> diff --git a/policy.sgml b/policy.sgml
> index 404dc73..f9fdbf7 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -6955,12 +6955,13 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
>character.
>  
>
>
>  
> -  The requirement for amd64 to use /lib64
> -  for 64 bit binaries is removed.
> +  The requirement for amd64 to use /lib64 for
> +  64 bit binaries is removed. Only the dynamic linker is
> +  allowed to use this directory.
>  
>
>
>  
>The requirement for object files, internal binaries, and
> @@ -6983,10 +6984,14 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
>  use in cross-installation of library packages from other
>  architectures, as part of multiarch.
>
>  
>  
> +  No package for a 64 bit architecture may install files
> +  in /usr/lib64/ or in a subdirectory of it.
> +
> +
>The requirement for C and C++ headers files to be
>accessible through the search path
>/usr/include/ is amended, permitting files to
>be accessible through the search path
>/usr/include/triplet where

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#630174: debian-policy: forbid installation into /lib64

[Niels Thykier]

On Tue, 9 Jun 2015 23:00:51 +0200 Bill Allombert 
wrote:
>[...]
> 
> OK, here a new patch.
> 
> Seconds welcome!
> 
> Cheers,
> -- 
> Bill. 
> 
> Imagine a large red swirl here. 

Hi,

I second the following change proposed by Bill:

> diff --git a/policy.sgml b/policy.sgml
> index 404dc73..f9fdbf7 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -6955,12 +6955,13 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
>character.
>  
>
>
>  
> -  The requirement for amd64 to use /lib64
> -  for 64 bit binaries is removed.
> +  The requirement for amd64 to use /lib64 for
> +  64 bit binaries is removed. Only the dynamic linker is
> +  allowed to use this directory.
>  
>
>
>  
>The requirement for object files, internal binaries, and
> @@ -6983,10 +6984,14 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
>  use in cross-installation of library packages from other
>  architectures, as part of multiarch.
>
>  
>  
> +  No package for a 64 bit architecture may install files
> +  in /usr/lib64/ or in a subdirectory of it.
> +
> +
>The requirement for C and C++ headers files to be
>accessible through the search path
>/usr/include/ is amended, permitting files to
>be accessible through the search path
>/usr/include/triplet where

Thanks,
~Niels




signature.asc
Description: OpenPGP digital signature

Bug#630174: debian-policy: forbid installation into /lib64

[Bill Allombert]

On Tue, May 12, 2015 at 09:21:13AM +0900, Charles Plessy wrote:
 Le Mon, May 11, 2015 at 11:30:54AM +0200, Bill Allombert a écrit :
  
  We should document that to prevent /lib64 to be used for wrong purpose.
  
   In any case I'm not quite sure whether shipping files in lib64 in amd64
   packages (juffed/juffed-dev and zynaddsubfx-dssi do this now) is OK.
  
  I only found 
  zynaddsubfx-dssi: /usr/lib64/dssi/libzynaddsubfx_dssi.so
  which I think is a RC bug.
  
  But note that this bug is about /lib64, not /usr/lib64
 
 Hi Bill,
 
 while the title is only about /lib64, the main text of the original message
 in for this bug is about /lib64 and /usr/lib64.

OK, here a new patch.

Seconds welcome!

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 
diff --git a/policy.sgml b/policy.sgml
index 404dc73..f9fdbf7 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -6955,12 +6955,13 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
   character.
 /p
   /item
   item
 p
-  The requirement for amd64 to use file/lib64/file
-  for 64 bit binaries is removed.
+  The requirement for amd64 to use file/lib64/file for
+  64 bit binaries is removed. Only the dynamic linker is
+  allowed to use this directory.
 /p
   /item
   item
 p
   The requirement for object files, internal binaries, and
@@ -6983,10 +6984,14 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
 use in cross-installation of library packages from other
 architectures, as part of ttmultiarch/tt.
   /footnote
 /p
 p
+  No package for a 64 bit architecture may install files
+  in file/usr/lib64//file or in a subdirectory of it.
+/p
+p
   The requirement for C and C++ headers files to be
   accessible through the search path
   file/usr/include//file is amended, permitting files to
   be accessible through the search path
   file/usr/include/vartriplet/var/file where

Bug#630174: debian-policy: forbid installation into /lib64

[Bill Allombert]

On Mon, May 11, 2015 at 11:30:54AM +0200, Bill Allombert wrote:
  In any case I'm not quite sure whether shipping files in lib64 in amd64
  packages (juffed/juffed-dev and zynaddsubfx-dssi do this now) is OK.
 
 I only found 
 zynaddsubfx-dssi: /usr/lib64/dssi/libzynaddsubfx_dssi.so
 which I think is a RC bug.

I reported it as 787919.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#630174: debian-policy: forbid installation into /lib64

[Bill Allombert]

On Mon, May 11, 2015 at 02:01:13PM +0500, Andrey Rahmatullin wrote:
 On Tue, Nov 29, 2011 at 12:45:25AM +0100, Bill Allombert wrote:
  This is the relevant part of the FHS (ill-advised imho, but required by the 
  LSB):
  
  -
  
  6.1.5. /lib64 and /lib32 : 64/32-bit libraries (architecture dependent)
  
The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place 
  64-bit
  libraries in /lib64, and 32-bit (or 31-bit on s390) libraries in /lib.
  The 64-bit architecture IA64 must place 64-bit libraries in /lib.
  
  Rationale:
  
This is a refinement of the general rules for /libqual and 
  /usr/libqual. The architectures PPC64, s390x, sparc64 and AMD64 support 
  support both 32-bit (for s390 more precise 31-bit) and 64-bit programs.
Using lib for 32-bit binaries allows existing binaries from the 32-bit
  systems to work without any changes: such binaries are expected to be 
  numerous.
  IA-64 uses a different scheme, reflecting the deprecation of 32-bit binaries
  (and hence libraries) on that architecture.
  
  -
  
  Of the five architectures mentioned above, only two are supported by full 
  Debian
  distributions: ia64 and amd64. (full support for s390x might appear in the 
  future).
  Since ia64 is listed as an exception, only amd64 is concerned by this FHS 
  part.
  (Note that the FHS ignores alpha and hppa64)
  
  As far as Debian is concerned /lib32 and /lib64 are wart necessary for 
  binary compatibility
  with other systems.
 Should we close this then?

We should document that to prevent /lib64 to be used for wrong purpose.

 In any case I'm not quite sure whether shipping files in lib64 in amd64
 packages (juffed/juffed-dev and zynaddsubfx-dssi do this now) is OK.

I only found 
zynaddsubfx-dssi: /usr/lib64/dssi/libzynaddsubfx_dssi.so
which I think is a RC bug.

But note that this bug is about /lib64, not /usr/lib64

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#630174: debian-policy: forbid installation into /lib64

[Andrey Rahmatullin]

On Tue, Nov 29, 2011 at 12:45:25AM +0100, Bill Allombert wrote:
 This is the relevant part of the FHS (ill-advised imho, but required by the 
 LSB):
 
 -
 
 6.1.5. /lib64 and /lib32 : 64/32-bit libraries (architecture dependent)
 
   The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place 
 64-bit
 libraries in /lib64, and 32-bit (or 31-bit on s390) libraries in /lib.
 The 64-bit architecture IA64 must place 64-bit libraries in /lib.
 
 Rationale:
 
   This is a refinement of the general rules for /libqual and 
 /usr/libqual. The architectures PPC64, s390x, sparc64 and AMD64 support 
 support both 32-bit (for s390 more precise 31-bit) and 64-bit programs.
   Using lib for 32-bit binaries allows existing binaries from the 32-bit
 systems to work without any changes: such binaries are expected to be 
 numerous.
 IA-64 uses a different scheme, reflecting the deprecation of 32-bit binaries
 (and hence libraries) on that architecture.
 
 -
 
 Of the five architectures mentioned above, only two are supported by full 
 Debian
 distributions: ia64 and amd64. (full support for s390x might appear in the 
 future).
 Since ia64 is listed as an exception, only amd64 is concerned by this FHS 
 part.
 (Note that the FHS ignores alpha and hppa64)
 
 As far as Debian is concerned /lib32 and /lib64 are wart necessary for binary 
 compatibility
 with other systems.
Should we close this then?

In any case I'm not quite sure whether shipping files in lib64 in amd64
packages (juffed/juffed-dev and zynaddsubfx-dssi do this now) is OK.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Bug#630174: debian-policy: forbid installation into /lib64

[Charles Plessy]

Le Mon, May 11, 2015 at 11:30:54AM +0200, Bill Allombert a écrit :
 
 We should document that to prevent /lib64 to be used for wrong purpose.
 
  In any case I'm not quite sure whether shipping files in lib64 in amd64
  packages (juffed/juffed-dev and zynaddsubfx-dssi do this now) is OK.
 
 I only found 
 zynaddsubfx-dssi: /usr/lib64/dssi/libzynaddsubfx_dssi.so
 which I think is a RC bug.
 
 But note that this bug is about /lib64, not /usr/lib64

Hi Bill,

while the title is only about /lib64, the main text of the original message
in for this bug is about /lib64 and /usr/lib64.

How about the following.

Packages must not install files in file/lib64/file and
file/usr/lib64/file.  The ttlibc6/tt package is exempted from this
restriction.

I think that we are practical enough that, if we need another core package to
ship files in these directories for a very good reason, this can happen before
a revised version of the Policy is released.

Have a nice day,

-- 
Charles


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#630174: debian-policy: forbid installation into /lib64

[Bill Allombert]

On Sun, Nov 27, 2011 at 01:28:30PM +0900, Charles Plessy wrote:
 Le Sat, Nov 26, 2011 at 09:52:57PM -0600, Steve Langasek a écrit :
  On Sun, Nov 27, 2011 at 11:55:20AM +0900, Charles Plessy wrote:
  
   According to apt-file, prohibiting to install files into /lib64 and 
   /usr/lib64
   on amd64 would make only one package RC-buggy, juffed, in its experimental
   version.
  
  I'm not sure why your apt-file invocation wouldn't have turned it up, but
  libc6 in unstable installs /lib64/ld-linux-x86-64.so.2.  So as written this
  would make libc RC buggy, which is not what we want.  (At the time of the
  previous discussion, libc was not installing this to /lib64; the change was
  made as a result of a more thorough analysis of the consequences of
  multiarch on i386 systems.)
  
  Also, this shouldn't spell out with architecture amd64.  Packages on *all*
  architectures must avoid use of /lib64 and /usr/lib64, with a handful of
  exceptions.
 
 Thanks a lot for the corrections.
 
 After apt-file update I can indeed see libc6 and two additional packages,
 scidavis and ugene.
 
 About /lib64/ld-linux-x86-64.so.2, does that mean that the Policy has to list
 exceptions, (for files or packages ?), or that the proposal is obsolete ?
 
 For the architectures, I was puzzled that Russ mentionned ‘with architecture
 amd64’ in his proposal and tried to not discard this information.  What
 achitectures, or which packages in which architectures, should be listed as
 exceptions ?

This is the relevant part of the FHS (ill-advised imho, but required by the 
LSB):

-

6.1.5. /lib64 and /lib32 : 64/32-bit libraries (architecture dependent)

  The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place 64-bit
libraries in /lib64, and 32-bit (or 31-bit on s390) libraries in /lib.
The 64-bit architecture IA64 must place 64-bit libraries in /lib.

Rationale:

  This is a refinement of the general rules for /libqual and 
/usr/libqual. The architectures PPC64, s390x, sparc64 and AMD64 support 
support both 32-bit (for s390 more precise 31-bit) and 64-bit programs.
  Using lib for 32-bit binaries allows existing binaries from the 32-bit
systems to work without any changes: such binaries are expected to be numerous.
IA-64 uses a different scheme, reflecting the deprecation of 32-bit binaries
(and hence libraries) on that architecture.

-

Of the five architectures mentioned above, only two are supported by full Debian
distributions: ia64 and amd64. (full support for s390x might appear in the 
future).
Since ia64 is listed as an exception, only amd64 is concerned by this FHS part.
(Note that the FHS ignores alpha and hppa64)

As far as Debian is concerned /lib32 and /lib64 are wart necessary for binary 
compatibility
with other systems.

Cheers,
-- 
Bill. ballo...@debian.org

Imagine a large red swirl here. 



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#630174: debian-policy: forbid installation into /lib64

[Charles Plessy]

user debian-pol...@lists.debian.org
tag 630174 + patch
usertags 630174 + normative
thanks

Le Sat, Jun 25, 2011 at 04:28:41PM -0500, Steve Langasek a écrit :
 On Sat, Jun 11, 2011 at 10:58:02PM +0200, Julien Cristau wrote:
  On Sat, Jun 11, 2011 at 13:49:53 -0700, Russ Allbery wrote:
 
   Currently, section 9.1.1 relaxes the FHS requirement that /lib64 and
   /usr/lib64 be used, but it doesn't prohibit installing files in that
   location.  However, due to the way Debian handles this (with symlinks),
   bad things happen in terms of tracking files and conflicts if packages
   install files into /lib64 and /usr/lib64 and rely on these symlinks.
 
   I think we should instead prohibit (must not) installing files into
   /lib64 and /usr/lib64 in packages with architecture amd64.
 
  Sounds sensible to me.
 
 I agree.

Here is a patch.

According to apt-file, prohibiting to install files into /lib64 and /usr/lib64
on amd64 would make only one package RC-buggy, juffed, in its experimental
version.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan
From 8a708ce2125835e537566fc1f75094d91076f573 Mon Sep 17 00:00:00 2001
From: Charles Plessy ple...@debian.org
Date: Sun, 27 Nov 2011 11:40:21 +0900
Subject: [PATCH] Forbid installation into /lib64 and /usr/lib64.

Closes: #630174
---
 policy.sgml |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/policy.sgml b/policy.sgml
index 3122632..47fbfb4 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -6185,8 +6185,8 @@ install -m644 debian/shlibs.varpackage/var debian/varpackage/var/DEBIAN/
   /item
   item
 p
-  The requirement for amd64 to use file/lib64/file
-  for 64 bit binaries is removed.
+  Packages with architecture amd64 must not install files
+  in file/lib64/file and file/usr/lib64/file.
 /p
   /item
   item
-- 
1.7.5.4

Bug#630174: debian-policy: forbid installation into /lib64

[Steve Langasek]

On Sun, Nov 27, 2011 at 11:55:20AM +0900, Charles Plessy wrote:
 Le Sat, Jun 25, 2011 at 04:28:41PM -0500, Steve Langasek a écrit :
  On Sat, Jun 11, 2011 at 10:58:02PM +0200, Julien Cristau wrote:
   On Sat, Jun 11, 2011 at 13:49:53 -0700, Russ Allbery wrote:

 Here is a patch.

 According to apt-file, prohibiting to install files into /lib64 and /usr/lib64
 on amd64 would make only one package RC-buggy, juffed, in its experimental
 version.

I'm not sure why your apt-file invocation wouldn't have turned it up, but
libc6 in unstable installs /lib64/ld-linux-x86-64.so.2.  So as written this
would make libc RC buggy, which is not what we want.  (At the time of the
previous discussion, libc was not installing this to /lib64; the change was
made as a result of a more thorough analysis of the consequences of
multiarch on i386 systems.)

Also, this shouldn't spell out with architecture amd64.  Packages on *all*
architectures must avoid use of /lib64 and /usr/lib64, with a handful of
exceptions.

-- 
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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

 From 8a708ce2125835e537566fc1f75094d91076f573 Mon Sep 17 00:00:00 2001
 From: Charles Plessy ple...@debian.org
 Date: Sun, 27 Nov 2011 11:40:21 +0900
 Subject: [PATCH] Forbid installation into /lib64 and /usr/lib64.
 
 Closes: #630174
 ---
  policy.sgml |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/policy.sgml b/policy.sgml
 index 3122632..47fbfb4 100644
 --- a/policy.sgml
 +++ b/policy.sgml
 @@ -6185,8 +6185,8 @@ install -m644 debian/shlibs.varpackage/var 
 debian/varpackage/var/DEBIAN/
/item
item
  p
 -  The requirement for amd64 to use file/lib64/file
 -  for 64 bit binaries is removed.
 +  Packages with architecture amd64 must not install files
 +  in file/lib64/file and file/usr/lib64/file.
  /p
/item
item
 -- 
 1.7.5.4
 


signature.asc
Description: Digital signature

Bug#630174: debian-policy: forbid installation into /lib64

[Charles Plessy]

Le Sat, Nov 26, 2011 at 09:52:57PM -0600, Steve Langasek a écrit :
 On Sun, Nov 27, 2011 at 11:55:20AM +0900, Charles Plessy wrote:
 
  According to apt-file, prohibiting to install files into /lib64 and 
  /usr/lib64
  on amd64 would make only one package RC-buggy, juffed, in its experimental
  version.
 
 I'm not sure why your apt-file invocation wouldn't have turned it up, but
 libc6 in unstable installs /lib64/ld-linux-x86-64.so.2.  So as written this
 would make libc RC buggy, which is not what we want.  (At the time of the
 previous discussion, libc was not installing this to /lib64; the change was
 made as a result of a more thorough analysis of the consequences of
 multiarch on i386 systems.)
 
 Also, this shouldn't spell out with architecture amd64.  Packages on *all*
 architectures must avoid use of /lib64 and /usr/lib64, with a handful of
 exceptions.

Thanks a lot for the corrections.

After apt-file update I can indeed see libc6 and two additional packages,
scidavis and ugene.

About /lib64/ld-linux-x86-64.so.2, does that mean that the Policy has to list
exceptions, (for files or packages ?), or that the proposal is obsolete ?

For the architectures, I was puzzled that Russ mentionned ‘with architecture
amd64’ in his proposal and tried to not discard this information.  What
achitectures, or which packages in which architectures, should be listed as
exceptions ?

I will update the patch or remove the patch tag according to the answers
(hoping keep BTS control echo low).

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#630174: debian-policy: forbid installation into /lib64

[Steve Langasek]

On Sat, Jun 11, 2011 at 10:58:02PM +0200, Julien Cristau wrote:
 On Sat, Jun 11, 2011 at 13:49:53 -0700, Russ Allbery wrote:

  Currently, section 9.1.1 relaxes the FHS requirement that /lib64 and
  /usr/lib64 be used, but it doesn't prohibit installing files in that
  location.  However, due to the way Debian handles this (with symlinks),
  bad things happen in terms of tracking files and conflicts if packages
  install files into /lib64 and /usr/lib64 and rely on these symlinks.

  I think we should instead prohibit (must not) installing files into
  /lib64 and /usr/lib64 in packages with architecture amd64.

 Sounds sensible to me.

I agree.

-- 
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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#630174: debian-policy: forbid installation into /lib64

[Russ Allbery]

Package: debian-policy
Version: 3.9.2.0
Severity: normal

Currently, section 9.1.1 relaxes the FHS requirement that /lib64 and
/usr/lib64 be used, but it doesn't prohibit installing files in that
location.  However, due to the way Debian handles this (with symlinks),
bad things happen in terms of tracking files and conflicts if packages
install files into /lib64 and /usr/lib64 and rely on these symlinks.

I think we should instead prohibit (must not) installing files into
/lib64 and /usr/lib64 in packages with architecture amd64.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

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

debian-policy depends on no packages.

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
ii  doc-base  0.10.1 utilities to manage online documen

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#630174: debian-policy: forbid installation into /lib64

[Julien Cristau]

On Sat, Jun 11, 2011 at 13:49:53 -0700, Russ Allbery wrote:

 Currently, section 9.1.1 relaxes the FHS requirement that /lib64 and
 /usr/lib64 be used, but it doesn't prohibit installing files in that
 location.  However, due to the way Debian handles this (with symlinks),
 bad things happen in terms of tracking files and conflicts if packages
 install files into /lib64 and /usr/lib64 and rely on these symlinks.
 
 I think we should instead prohibit (must not) installing files into
 /lib64 and /usr/lib64 in packages with architecture amd64.
 
Sounds sensible to me.

Cheers,
Julien



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org