On 2019-04-09 12:27, Andreas Beckmann wrote: > Package: libc6-x32,libc6-i386 > Version: 2.28-8 > Severity: serious > User: [email protected] > 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
[email protected] http://www.aurel32.net
signature.asc
Description: PGP signature
