Re: Debian Policy 4.1.0.0 released

[Russ Allbery]

Aurelien Jarno  writes:
> On 2017-08-22 09:42, Russ Allbery wrote:
>> Aurelien Jarno  writes:
>>> On 2017-08-21 14:35, Sean Whitton wrote:

 9.1.1
 Only the dynamic linker may install files to /lib64/.

>>> How is that supposed to work for the multilib glibc? For example
>>> libc6-amd64:i386 installs all its libraries into /lib64. We don't want
>>> to install these files in the multiarch path, as they will collide with
>>> the libc6:amd64 package. This is actually forbidden by the same
>>> paragraph of the policy (and that's a good thing).

>>> In the long term we should get ready of multilib now that we have
>>> multiarch, but it seems it's not something we are ready to do yet. I
>>> have added debian-...@lists.debian.org in Cc: as GCC is the main user of
>>> the multilib glibc.

>> Ack, thank you, we just didn't know about this and it didn't come up in
>> the discussion.  We can add an additional exception.  The goal here
>> wasn't to change any behavior of packages like that, only to keep
>> ordinary non-glibc, non-toolchain packages from using that directory
>> because of what Red Hat does or because of what the FHS says.

>> Would it resolve this to just make a general exception for libc?

> Yes, that would solve the issue.

Filed as Bug#885219 and I'll propose a diff in that bug.

-- 
Russ Allbery (r...@debian.org)   

Re: Debian Policy 4.1.0.0 released

[Aurelien Jarno]

On 2017-08-22 09:42, Russ Allbery wrote:
> Aurelien Jarno  writes:
> > On 2017-08-21 14:35, Sean Whitton wrote:
> 
> >> 9.1.1
> >> Only the dynamic linker may install files to /lib64/.
> 
> > How is that supposed to work for the multilib glibc? For example
> > libc6-amd64:i386 installs all its libraries into /lib64. We don't want
> > to install these files in the multiarch path, as they will collide with
> > the libc6:amd64 package. This is actually forbidden by the same
> > paragraph of the policy (and that's a good thing).
> 
> > In the long term we should get ready of multilib now that we have
> > multiarch, but it seems it's not something we are ready to do yet. I
> > have added debian-...@lists.debian.org in Cc: as GCC is the main user of
> > the multilib glibc.
> 
> Ack, thank you, we just didn't know about this and it didn't come up in
> the discussion.  We can add an additional exception.  The goal here wasn't
> to change any behavior of packages like that, only to keep ordinary
> non-glibc, non-toolchain packages from using that directory because of
> what Red Hat does or because of what the FHS says.
> 
> Would it resolve this to just make a general exception for libc?

Yes, that would solve the issue.

Thanks,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Re: Debian Policy 4.1.0.0 released

[Russ Allbery]

Aurelien Jarno  writes:
> On 2017-08-21 14:35, Sean Whitton wrote:

>> 9.1.1
>> Only the dynamic linker may install files to /lib64/.

> How is that supposed to work for the multilib glibc? For example
> libc6-amd64:i386 installs all its libraries into /lib64. We don't want
> to install these files in the multiarch path, as they will collide with
> the libc6:amd64 package. This is actually forbidden by the same
> paragraph of the policy (and that's a good thing).

> In the long term we should get ready of multilib now that we have
> multiarch, but it seems it's not something we are ready to do yet. I
> have added debian-...@lists.debian.org in Cc: as GCC is the main user of
> the multilib glibc.

Ack, thank you, we just didn't know about this and it didn't come up in
the discussion.  We can add an additional exception.  The goal here wasn't
to change any behavior of packages like that, only to keep ordinary
non-glibc, non-toolchain packages from using that directory because of
what Red Hat does or because of what the FHS says.

Would it resolve this to just make a general exception for libc?

-- 
Russ Allbery (r...@debian.org)   

Re: Debian Policy 4.1.0.0 released

[Aurelien Jarno]

Hi,

On 2017-08-21 14:35, Sean Whitton wrote:
> Hello everyone,
> 
> Debian Policy 4.1.0.0 is on its way into unstable.
> 
> The source of the Policy Manual is now in reStructuredText, and the
> Sphinx toolchain is used to produce our output formats.  This has
> enabled us to introduce new ePub and Texinfo output formats, so it's now
> more comfortable to read Policy on the beach, and in Emacs.
> 
> Many thanks to Hideki Yamane for writing the rST conversion scripts and
> pushing the project forward, and David Bremner for help proofreading.
> Russ Allbery and I updated the build system.
> 
> We are seeking volunteers to design a Debian documentation Sphinx
> theme.  The maintainers of other core pieces of Debian documentation are
> also looking to move to Sphinx, so such a theme would see wide use.
> 
> Here are the changes from the previously announced version of Policy
> (4.0.1):
 
> 9.1.1
> Only the dynamic linker may install files to /lib64/.

How is that supposed to work for the multilib glibc? For example
libc6-amd64:i386 installs all its libraries into /lib64. We don't want
to install these files in the multiarch path, as they will collide with
the libc6:amd64 package. This is actually forbidden by the same
paragraph of the policy (and that's a good thing).

In the long term we should get ready of multilib now that we have
multiarch, but it seems it's not something we are ready to do yet. I
have added debian-...@lists.debian.org in Cc: as GCC is the main user
of the multilib glibc.

> No package for a 64 bit architecture may install files to
> /usr/lib64/ or any subdirectory.

I guess you want to use the same formulation for /lib64, it should only
be for 64-bit architecture. That said you should define what is a 64 bit
architecture. On x32 (not an official architecture) for example
libc6-amd64:x32 installs files in /lib64 and libc6-amd64-dev:x32
installs file in /usr/lib64. Is it considered a 32-bit architecture or
a 64-bit architecture?

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature