Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1070774 > unrolled thread

Bug#949395: dpkg: Old packaged files not always removed, causing various issues

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#949395: dpkg: Old packaged files not always removed, causing various issues Andreas Metzler <ametzler@bebt.de> - 2021-09-11 18:10 +0200
    Bug#949395: dpkg: Old packaged files not always removed, causing various issues Simon McVittie <smcv@debian.org> - 2021-09-11 19:30 +0200
      Bug#949395: dpkg: Old packaged files not always removed, causing various issues Andreas Metzler <ametzler@bebt.de> - 2021-09-12 15:00 +0200
        Bug#949395: dpkg: Old packaged files not always removed, causing various issues Simon McVittie <smcv@debian.org> - 2021-09-12 16:20 +0200

#1070774 — Bug#949395: dpkg: Old packaged files not always removed, causing various issues

Control: block 984884 by 949395

On 2020-01-20 Simon McVittie <smcv@debian.org> wrote:
> Package: dpkg
> Version: 1.19.7
> Severity: normal
> Tags: unreproducible

> Maintainers have seen bugs in various packages where an old file (one
> that was shipped in an old .deb, but not under the same name in a new
> .deb) appears to have been retained on-disk rather than deleted. At some
> later time, perhaps months or years later, that file causes an upgrade
> failure triggered by the superseding file moving from one directory in
> a search path to another.
[...]

Hello,

I have got another instance in libgcrypt20
<https://bugs.debian.org/984884> but the actual error (leaving files
behind) happened ages ago; the leftovers are from pre-stretch versions
of libgcrypt.

These leftovers trigger an error now, because the library has moved from
/lib to /usr/lib in buster and ldconfig activates both the leftover and
the proper copy (by adding libgcrypt.so.20 symlinks). /lib has the
higher priority and wins.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

[toc] | [next] | [standalone]

#1070788

On Sat, 11 Sep 2021 at 18:00:50 +0200, Andreas Metzler wrote:
> On 2020-01-20 Simon McVittie <smcv@debian.org> wrote:
> > Maintainers have seen bugs in various packages where an old file (one
> > that was shipped in an old .deb, but not under the same name in a new
> > .deb) appears to have been retained on-disk rather than deleted. At some
> > later time, perhaps months or years later, that file causes an upgrade
> > failure triggered by the superseding file moving from one directory in
> > a search path to another.
> 
> I have got another instance in libgcrypt20
> <https://bugs.debian.org/984884> but the actual error (leaving files
> behind) happened ages ago; the leftovers are from pre-stretch versions
> of libgcrypt.
> 
> These leftovers trigger an error now, because the library has moved from
> /lib to /usr/lib in buster and ldconfig activates both the leftover and
> the proper copy (by adding libgcrypt.so.20 symlinks). /lib has the
> higher priority and wins.

This is the same failure mode as was seen in glib2.0, and we were never
able to work out why. In the glib2.0 bugs, the leftover versions were
older: from wheezy (we think) in #954960, and from half way through the
wheezy -> jessie cycle in #894763, #896019 and #955331.

I asked the Technical Committee for advice about how to deal with this in
glib2.0, and we came to the conclusion that cleaning up the old library
in the maintainer scripts was the least-bad option.

There's a script in glib2.0 that can be called from a maintainer script
to work around this. I've only used it for GLib, but it should work
equally for any library that moved from /lib/MULTIARCH to /usr/lib/MULTIARCH,
since it takes a bug number, a multiarch tuple and a SONAME as command-line
options:
https://salsa.debian.org/gnome-team/glib/-/blob/debian/bullseye/debian/clean-up-unmanaged-libraries

Example use in a postinst (look for "cleanup"):
https://salsa.debian.org/gnome-team/glib/-/blob/debian/bullseye/debian/libglib2.0-0.postinst.in

GLib uses a generated postinst where #MULTIARCH# gets replaced
by the multiarch tuple of the package. As far as I know, this
is going to be necessary for any multiarch library that will use
my clean-up-unmanaged-libraries script, because dpkg tells us the
DPKG_MAINTSCRIPT_PACKAGE and DPKG_MAINTSCRIPT_ARCH, but there is no
DPKG_MAINTSCRIPT_MULTIARCH.

I'll open a separate wishlist bug for DPKG_MAINTSCRIPT_MULTIARCH,
because that would be useful to have - GLib needed it anyway, even before
the cleanup was implemented, to handle GIO plugins.

    smcv

[toc] | [prev] | [next] | [standalone]

#1070885

On 2021-09-11 Simon McVittie <smcv@debian.org> wrote:
[...]
> GLib uses a generated postinst where #MULTIARCH# gets replaced
> by the multiarch tuple of the package. As far as I know, this
> is going to be necessary for any multiarch library that will use
> my clean-up-unmanaged-libraries script, because dpkg tells us the
> DPKG_MAINTSCRIPT_PACKAGE and DPKG_MAINTSCRIPT_ARCH, but there is no
> DPKG_MAINTSCRIPT_MULTIARCH.

> I'll open a separate wishlist bug for DPKG_MAINTSCRIPT_MULTIARCH,
> because that would be useful to have - GLib needed it anyway, even before
> the cleanup was implemented, to handle GIO plugins.

Hello,

dpkg-buildpackage sets DEB_BUILD_MULTIARCH but afaiui
one cannot /rely/ on it being set since it is not listed in policy 4.9.
I will probably make sure it is set in debian/rules and use
#ENV.DEB_BUILD_MULTIARCH#

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

[toc] | [prev] | [next] | [standalone]

#1070893

On Sun, 12 Sep 2021 at 14:47:20 +0200, Andreas Metzler wrote:
> On 2021-09-11 Simon McVittie <smcv@debian.org> wrote:
> > GLib uses a generated postinst where #MULTIARCH# gets replaced
> > by the multiarch tuple of the package.
>
> dpkg-buildpackage sets DEB_BUILD_MULTIARCH but afaiui
> one cannot /rely/ on it being set since it is not listed in policy 4.9.
> I will probably make sure it is set in debian/rules and use
> #ENV.DEB_BUILD_MULTIARCH#

You want DEB_HOST_MULTIARCH, not DEB_BUILD_MULTIARCH, for this.  When
cross-compiling, DEB_BUILD_MULTIARCH is the machine on which the package
is being built, which is only rarely an important piece of information.

(For example if you cross-compile a package for mipsel on amd64, the host
architecture is mipsel and the build architecture is amd64. The multiarch
tuple my script would need from the postinst is the one for mipsel.)

If in doubt, the _HOST_ variables are usually the right ones to look at.

    smcv

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web