Bug#926699: libc6-{i386,x32}: installing, removing, reinstalling in a --merged-usr system results in unmerged /lib{32,x32}

2019-08-17 Thread Marco d'Itri
On Aug 17, Aurelien Jarno  wrote:

> > > The preinst scripts could check whether the package is being installed
> > > in a --merged-usr environment and create (dangling) symlinks if
> > > /usr/lib{32,x32} is missing. And postrm remove could recreate them if
> > > they went missing.
Yes: this is how I hoped that this could be implemented, to stop having 
useles e.g. /libx32/ on all amd64 systems which will never see x32 
packages.

> As explained it's not a bug of the glibc package, but a design flaw of
> usrmerge. I am therefore reassigning the bug to debootstrap + usrmerge.
Do you have any suggestions about how you would like this to be fixed?

-- 
ciao,
Marco


signature.asc
Description: PGP signature


Bug#926699: libc6-{i386,x32}: installing, removing, reinstalling in a --merged-usr system results in unmerged /lib{32,x32}

2019-08-17 Thread Aurelien Jarno
reassign -1 debootstrap,usrmerge
thanks

On 2019-04-09 16:53, Aurelien Jarno wrote:
> On 2019-04-09 12:27, Andreas Beckmann wrote:
> > Package: libc6-x32,libc6-i386
> > Version: 2.28-8
> > Severity: serious
> > User: debian...@lists.debian.org
> > Usertags: piuparts
> > 
> > Hi,
> > 
> > during a test with piuparts in a --merged-usr environment I noticed that
> > installing, removing, and installing again a package shipping /lib32,
> > /libx32 will actually unmerge that directory.
> > The package will take ownership of the preexisting symlinks
> > /lib{32,x32} -> /usr/lib{32,x32} that were created by debootstrap,
> > remove them and create plain /usr/lib{32,x32} directories in the next
> > installation.
> > (/lib64 should be mostly safe due to /lib64/ld-linux-x86-64.so.2, but
> > perhaps on !x86 architectures)

/lib64 is an issue for at least libc6:amd64 on an i386 system. And there
are many more cases if you also consider other official architectures
and ports architectures.

> Hmm the only fault of the libc6-i386 and libc6-x32 packages (plus I
> guess all the other bi/tri-arch ones on other architectures) is to be
> the last user of those directory when being removed. They do not do
> anything tricky in their directories.
> 
> > The preinst scripts could check whether the package is being installed
> > in a --merged-usr environment and create (dangling) symlinks if
> > /usr/lib{32,x32} is missing. And postrm remove could recreate them if
> > they went missing.

The glibc maintainer scripts are already cluttered with many ugly and
fragile workarounds to handle the co-installability of foreign and biarch
glibc. I do not want to adds more workarounds that might will make the
whole things a nightmare.

> This looks like an ugly workaround to me, and might not work if a
> package start adding files there without depending on libc6. This looks
> to me like a flaw in the usrmerge design. The base-files package is
> designed to prevent directories or symlinks to be removed, so I wonder
> if we need a usrmerge version of it.

As explained it's not a bug of the glibc package, but a design flaw of
usrmerge. I am therefore reassigning the bug to debootstrap + usrmerge.

I am not opposed to a workaround in the glibc package, kept for one
release cycle only, *once a real solution* is implemented for this bug.

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


signature.asc
Description: PGP signature


Bug#926699: libc6-{i386,x32}: installing, removing, reinstalling in a --merged-usr system results in unmerged /lib{32,x32}

2019-04-23 Thread Julien Cristau
On Tue, Apr 09, 2019 at 12:27:45PM +0200, Andreas Beckmann wrote:
> Package: libc6-x32,libc6-i386
> Version: 2.28-8
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts in a --merged-usr environment I noticed that
> installing, removing, and installing again a package shipping /lib32,
> /libx32 will actually unmerge that directory.

So I understand that may be undesirable, but what is the justification
for this being "serious"?  Does anything actually break?

Cheers,
Julien



Bug#926699: libc6-{i386,x32}: installing, removing, reinstalling in a --merged-usr system results in unmerged /lib{32,x32}

2019-04-09 Thread Aurelien Jarno
On 2019-04-09 12:27, Andreas Beckmann wrote:
> Package: libc6-x32,libc6-i386
> Version: 2.28-8
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts in a --merged-usr environment I noticed that
> installing, removing, and installing again a package shipping /lib32,
> /libx32 will actually unmerge that directory.
> The package will take ownership of the preexisting symlinks
> /lib{32,x32} -> /usr/lib{32,x32} that were created by debootstrap,
> remove them and create plain /usr/lib{32,x32} directories in the next
> installation.
> (/lib64 should be mostly safe due to /lib64/ld-linux-x86-64.so.2, but
> perhaps on !x86 architectures)

Hmm the only fault of the libc6-i386 and libc6-x32 packages (plus I
guess all the other bi/tri-arch ones on other architectures) is to be
the last user of those directory when being removed. They do not do
anything tricky in their directories.

> The preinst scripts could check whether the package is being installed
> in a --merged-usr environment and create (dangling) symlinks if
> /usr/lib{32,x32} is missing. And postrm remove could recreate them if
> they went missing.

This looks like an ugly workaround to me, and might not work if a
package start adding files there without depending on libc6. This looks
to me like a flaw in the usrmerge design. The base-files package is
designed to prevent directories or symlinks to be removed, so I wonder
if we need a usrmerge version of it.

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


signature.asc
Description: PGP signature


Bug#926699: libc6-{i386,x32}: installing, removing, reinstalling in a --merged-usr system results in unmerged /lib{32,x32}

2019-04-09 Thread Andreas Beckmann
Package: libc6-x32,libc6-i386
Version: 2.28-8
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts in a --merged-usr environment I noticed that
installing, removing, and installing again a package shipping /lib32,
/libx32 will actually unmerge that directory.
The package will take ownership of the preexisting symlinks
/lib{32,x32} -> /usr/lib{32,x32} that were created by debootstrap,
remove them and create plain /usr/lib{32,x32} directories in the next
installation.
(/lib64 should be mostly safe due to /lib64/ld-linux-x86-64.so.2, but
perhaps on !x86 architectures)

The preinst scripts could check whether the package is being installed
in a --merged-usr environment and create (dangling) symlinks if
/usr/lib{32,x32} is missing. And postrm remove could recreate them if
they went missing.

Andreas