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