Re: [PATCH] Symlink src/sh/dpkg-error.sh into build directory

Hi, On 6/12/24 11:54, Guillem Jover wrote: This is needed to run the tests during an out-of-tree build I guess this is for the functional test suite? What runes are you using to run it out-of-tree? $ make installtest DPKG_BUILDTREE=/tmp/dpkg I also have an evil bash script that sets up a

[PATCH] Symlink src/sh/dpkg-error.sh into build directory

This is needed to run the tests during an out-of-tree build --- configure.ac | 1 + 1 file changed, 1 insertion(+) diff --git a/configure.ac b/configure.ac index 36db52e71..cc2027534 100644 --- a/configure.ac +++ b/configure.ac @@ -246,6 +246,7 @@ AC_DEFINE([PACKAGE_RELEASE], [PACKAGE_VERSION "

Salsa CI broken

Hi, Builds on Salsa terminate with PO4A man.stamp Undefined subroutine ::Po4a::Pod::dgettext called at /usr/share/perl5/Locale/Po4a/Pod.pm line 94, <$fh> line 21. I might investigate later, but if someone has seen that problem before and knows what it is, that would possibly

[PATCH] Add missing

--- lib/dpkg/varbuf.h | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/dpkg/varbuf.h b/lib/dpkg/varbuf.h index 99d9f0691..5cc9718c7 100644 --- a/lib/dpkg/varbuf.h +++ b/lib/dpkg/varbuf.h @@ -23,6 +23,7 @@ #define LIBDPKG_VARBUF_H #include +#include #include #include -- 2.39.2

Re: [PATCH] cleanup: Pull in for memchr

Hi Guillem, On 3/20/24 08:59, Guillem Jover wrote: Thanks! I ended up including this unconditionally (also because we are not explicitly checking for this header which should always be there, and if something else is checking for it, that would be an internal implementation detail that might

[PATCH] cleanup: Pull in for memchr

This needs further inspection on more systems --- lib/compat/strnlen.c | 4 1 file changed, 4 insertions(+) diff --git a/lib/compat/strnlen.c b/lib/compat/strnlen.c index d02bb4bbd..6a7eb0454 100644 --- a/lib/compat/strnlen.c +++ b/lib/compat/strnlen.c @@ -22,6 +22,10 @@ #include

[PATCH] cleanup: make memcpy check -Werror safe

--- configure.ac | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index b084ade12..1daf4b1de 100644 --- a/configure.ac +++ b/configure.ac @@ -207,7 +207,21 @@ DPKG_CHECK_COMPAT_FUNCS([\ alphasort \ unsetenv \ ])

[PATCH] Add db-fsys-load.c to POTFILES.in

--- po/POTFILES.in | 1 + 1 file changed, 1 insertion(+) diff --git a/po/POTFILES.in b/po/POTFILES.in index b38797ad7..a2386011a 100644 --- a/po/POTFILES.in +++ b/po/POTFILES.in @@ -17,6 +17,7 @@ lib/dpkg/db-ctrl-upgrade.c lib/dpkg/db-fsys-digest.c lib/dpkg/db-fsys-divert.c

Re: [PATCH] Factor out common code for reloading database files

Hi Guillem, On 3/18/24 01:28, Guillem Jover wrote: Attached is what I had, which I've polished a bit more now. Will include in my next push. Nice, will rebase my branch on top of that. The new file probably needs to be added to po/POTFILES.in as well, since it contains translatable

Re: [PATCH] Factor out common code for reloading database files

On 17.03.24 08:27, Simon Richter wrote: --- lib/dpkg/Makefile.am| 1 + lib/dpkg/db-fsys-common.c | 87 + lib/dpkg/db-fsys-divert.c | 43 -- lib/dpkg/db-fsys-override.c | 50 + lib/dpkg/dpkg-db.h

Another usrmerge complication

Hi, because life isn't hard enough as it is: When /bin is a symlink to usr/bin, and I install two packages, where one installs /bin/foo and the other installs /usr/bin/foo, then, if both are installed in the same dpkg invocation, the contents of the first package end up being installed,

[PATCH] Valgrind support for test suite

--- tests/Makefile | 4 tests/Test.mk | 17 +++-- 2 files changed, 15 insertions(+), 6 deletions(-) diff --git a/tests/Makefile b/tests/Makefile index 5d8309608..5d3f30ee2 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -141,6 +141,10 @@ test:: $(test_targets)

[PATCH] Factor out common code for reloading database files

@@ -0,0 +1,87 @@ +/* + * libdpkg - Debian packaging suite library routines + * db-fsys-common.c - Common handling for admindb files + * + * Copyright © 2008-2012 Guillem Jover + * Copyright © 2022 Simon Richter + * + * This is free software; you can redistribute it and/or modify + * it under

Scriptable interface for "set package selection to this set"

Hi, I'm trying to build a small script to synchronize the package installation sets of a bunch of machines. My current approach is to simply run dpkg --clear-selections dpkg --set-selections I believe that this is the only interface that allows me to set the package selection

Re: Removing dpkg arch definitions for uclinux-any?

Hi, On 13.11.23 19:08, Guillem Jover wrote: I was checking for dpkg arch definitions to cleanup and stumbled over the uclinux-any ones (added as part of #455501), where I noticed the µCLinux fork got merged into mainline Linux in 2.5.46, and then several of the no-MMU ports got removed from

Bug#910377: System-critical package management

Hi, On 18.09.23 19:38, Julian Andres Klode wrote: I'm not sure how that works because you'd need to respawn yourself with systemd-inhibit, whereas the API essentially gives you a file descriptor over dbus that you keep open until it is safe to reboot. popen("systemd-inhibit ... cat",

Re: System-critical package management

Hi, On 18.09.23 19:38, Julian Andres Klode wrote: I'm not sure how that works because you'd need to respawn yourself with systemd-inhibit, whereas the API essentially gives you a file descriptor over dbus that you keep open until it is safe to reboot. popen("systemd-inhibit ... cat",

Re: System-critical package management

Hello, The lack of any system of recognition for packages that are critical to system operation impedes the reliability of Debian-based systems. For example, a reboot during a background package upgrade process on critical system packages unbeknownst to the user may result in the system

Re: Possible workaround/fix for usrmerge issues with dpkg-query -S (#858331 / #848622)

Hi, On 7/8/23 22:55, Eric de Ruiter wrote: The idea is simple: if you specify you want to match on realpath (for now by prefixing the path with "realpath:"); it will search for files matching the basename of the given path and does an extra check to only return matches where the realpath of

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi, On 6/21/23 20:33, Guillem Jover wrote: I don't think we disagree (?), I probably didn't express myself clearly. The fact that no package ships those symlinks *is* and *has* been a problem, and what I've been saying all along, this will be the only correct way to let dpkg know whether there

Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

Hi, On 5/18/23 18:08, Luca Boccassi wrote: Without it, leaving them in place makes no difference for usrmerged systems, and allows derived distributions that don't need usrmerge to continue using our packages. Not quite. Having packages only ship files under /usr (and possibly /etc) is very

Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

Hi, On 5/18/23 02:15, Sam Hartman wrote: Helmut> I think at this point, we have quite universal consensus Helmut> about the goal of moving files to their canonical location Helmut> (i.e. from / to /usr) as a solution to the aliasing problems Helmut> while we do not have

Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

Hi, On 5/12/23 02:51, Luca Boccassi wrote: Or alternatively, we can establish that a documentation/post-facto approach is enough for derivatives, and then that's valid for all changes and transitions. For the context of this bug, the notice *is* the after-the-fact documentation of an

Re: dpkg currently warning about merged-usr systems (revisited)

Hi Luca, [dropping the tech-ctte bug Cc, because most of this mail is irrelevant to that discussion, I'll send a separate mail for that one paragraph] On 5/12/23 02:51, Luca Boccassi wrote: The crux of the issue is that we are hearing how negatively affecting derivatives in any way, even

Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

Hi, On 5/11/23 10:59, Sean Whitton wrote: Dear ctte, please consider overruling the dpkg maintainer to include the patch from #994388[1]. Currently dpkg contains code to emit the merged-/usr warning, that's dead code on Debian, but which becomes active when packages from the Debian archive

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi, On 5/8/23 20:38, Luca Boccassi wrote: [local diversions] Sure, they are supported in the sense that they can be enabled, and then you get to keep the pieces. They are supported in the sense that someone actually added an explicit flag for dpkg-divert for specifically this feature and

Corner case: can a package owning a diversion disappear?

Hi, There are a few very unlikely corner cases where I'm unsure what would be expected of dpkg: 1. a package not providing a diverted file, and then disappearing pkg-a contains /x and registers a diversion /y -> z. pkg-b contains /y pkg-c Replaces pkg-a and contains /x Installing pkg-c

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi, On 5/7/23 18:14, Ansgar wrote: Is there any specific reason why specifically diversions are a problem where "it might work" is not sufficient? That is, why should we divert from the usual standard for dealing with packages outside the Debian ecosystem here? Locally created diversions are

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi, On 06.05.23 21:28, Luca Boccassi wrote: [shipping usrmerge symlinks in packages] In the far future I'd like for these details to be owned by image builders/launchers/setup processes rather than a package, but this can be discussed separately and independently, no need to be tied to this

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi, On 06.05.23 07:11, Luca Boccassi wrote: - every package is forcefully canonicalized as soon as trixie is open for business You will also need to ship at least - /lib -> usr/lib (on 32 bit) - /lib64 -> usr/lib64 (on 64 bit) as a symlink either in the libc-bin package or any other

Re: [PATCH] Warn for unknown info files in packages

Hi, On 06.05.23 05:58, Guillem Jover wrote: Debian Policy forbids info files not mentioned in Policy, except if their names start with an underscore to flag them as non-critical. I think you might be mixing up .deb ar members with entries in the control member in the .deb? Oof, yes. -_-

[PATCH] Warn for unknown info files in packages

Debian Policy forbids info files not mentioned in Policy, except if their names start with an underscore to flag them as non-critical. --- src/main/unpack.c | 29 + tests/t-multiarch/Makefile | 24 2 files changed, 41 insertions(+), 12

[PATCH 2/2] Mark functions in headers as inline

--- lib/dpkg/perf.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/dpkg/perf.h b/lib/dpkg/perf.h index a46792a43..48e69ccde 100644 --- a/lib/dpkg/perf.h +++ b/lib/dpkg/perf.h @@ -47,7 +47,7 @@ perf_ts_sub(struct timespec *a, struct timespec *b, struct timespec *res)

[PATCH 1/2] Make headers self-contained

--- lib/dpkg/command.h | 2 ++ lib/dpkg/db-fsys.h | 2 ++ lib/dpkg/parsedump.h | 1 + 3 files changed, 5 insertions(+) diff --git a/lib/dpkg/command.h b/lib/dpkg/command.h index 7d2098a29..09ec92ac7 100644 --- a/lib/dpkg/command.h +++ b/lib/dpkg/command.h @@ -23,6 +23,8 @@ #include

[PATCH] Ignore TAGS

This file can be optionally built, and is helpful in navigating the source tree, but should never be checked in. --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index a5edb85b8..19bdd9e73 100644 --- a/.gitignore +++ b/.gitignore @@ -17,6 +17,7 @@ .libs/

[PATCH] Rename .gitinore -> .gitignore

This seems to be a mistake. --- tests/dpkginst/{.gitinore => .gitignore} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename tests/dpkginst/{.gitinore => .gitignore} (100%) diff --git a/tests/dpkginst/.gitinore b/tests/dpkginst/.gitignore similarity index 100% rename from

[PATCH] Factor out common code for reloading database files

-common.c @@ -0,0 +1,84 @@ +/* + * libdpkg - Debian packaging suite library routines + * db-fsys-common.c - Common handling for admindb files + * + * Copyright © 2008-2012 Guillem Jover + * Copyright © 2022 Simon Richter + * + * This is free software; you can redistribute it and/or modify + * it under

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi, On 05.05.23 18:36, Timo Röhling wrote: - it is not an error to register a diversion for an alias of an existing diversion, provided the package and target matches, this is a no-op - it is not an error to unregister a diversion for an alias of a path that has been unregistered previously,

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi, On 04.05.23 20:26, Helmut Grohne wrote: From my point of view, the ultimate goal here should be moving all files to their canonical location and thereby make aliasing effects irrelevant. Do you confirm? Yes, that would solve the problem for the current transition without any changes in

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi, On 03.05.23 19:19, Helmut Grohne wrote: What still applies here is that we can have usr-is-merged divert /usr/bin/dpkg-divert and have it automatically duplicate any possibly aliased diversion and then the diverter may Pre-Depends: usr-is-merged (>=...) to have its diversions duplicated.

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi, On 30.04.23 03:08, Marvin Renich wrote: My understanding from following this thread (and others) is that dpkg has a bug that can easily be triggered by a sysadmin replacing a directory with a symlink (and some other necessary conditions that don't happen very often), which is explicitly

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi, On Thu, Apr 27, 2023 at 12:34:06AM +0200, Helmut Grohne wrote: > Ok, let's move on. I've proposed diversions as a cure, but in reality > diversions are a problem themselves. Consider that > cryptsetup-nuke-password diverts /lib/cryptsetup/askpass, which is > usually owned by cryptsetup. If

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi, On Thu, Apr 27, 2023 at 12:34:06AM +0200, Helmut Grohne wrote: > At some point the question becomes: Do we want that complexity inside > dpkg (aka DEP 17 or some variant of it) or outside of dpkg (i.e. what > we're talking about here). It seems clear at this time, that complexity > is

Re: DEP 17: Improve support for directory aliasing in dpkg

> to its canonical location without having any trouble even with an > unmodified dpkg. So from my pov, the question about important files can > be disregarded. I hope Simon Richter agrees. Yes, the relevant code at https://github.com/guillemj/dpkg/blob/main/src/main/unpack.c#L749 alre

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi Helmut, On 22.04.23 10:44, Helmut Grohne wrote: Dpkg already has defined behaviour for directory vs symlink: the directory wins. In principle a future version of dpkg could change that, but /lib/ld-linux.so.2 is just too special, we'd never want to have a package that actually moves it.

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi, On 22.04.23 11:36, Helmut Grohne wrote: For clarity let me propose the following requirements for the definition of done: * All files shipped in Debian packages are shipped in their canonical location rather than an aliased path. With proper support in dpkg, that is even somewhat

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi, On 21.04.23 15:03, Raphael Hertzog wrote: Here you are considering all files, but for the purpose of our issue, we can restrict ourselves to the directories known by dpkg. We really only care about directories that have been turned into symlinks (or packaged symlinks that are pointing to

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi, On Fri, Apr 21, 2023 at 02:15:54PM +0200, Raphael Hertzog wrote: I'd like to express some disappointment that nobody replied publicly sofar. There were a few replies on the dpkg mailing list. Last year's developer survey concluded that "Debian should complete the merged-/usr

Re: DEP 17: Improve support for directory aliasing in dpkg

Hi, On 08.04.23 04:35, Guillem Jover wrote: A little later, Simon Richter also looked into the problem (https://lists.debian.org/debian-dpkg/2022/12/msg00023.html), but remained silent after the initial post. Yes, I am quite busy, but it's not forgotten. I keep adding new test cases

another usrmerge branch

Hi, I've also started work on getting usrmerge back into a sensible state, current progress is at https://salsa.debian.org/sjr/dpkg/-/tree/wip-canonical-paths All of these commits obviously need to be rewritten a few times, but the general idea should be clear: - all paths that can

Bug#951479: [files list file for package 'base-passwd' is missing final newline] [debian buster 10.3]

Hi, On Mon, Feb 17, 2020 at 04:49:44PM +0100, Jean-Marc LACROIX wrote: > >Could you attach the old base-passwd.list file? > yes, in attached file. That file has a sensible size, but consists of only zeroes. This typically happens with file systems that have metadata only journaling after a

Bug#951479: [files list file for package 'base-passwd' is missing final newline] [debian buster 10.3]

Hi, On Mon, Feb 17, 2020 at 10:31:25AM +0100, Jean-Marc LACROIX wrote: > dpkg: unrecoverable fatal error, aborting: > files list file for package 'base-passwd' is missing final newline > E: Sub-process /usr/bin/dpkg returned an error code (2) That file is generated by dpkg on installation, so

Bug#846405: dpkg-shlibdeps: scales badly for many binaries

Package: dpkg Version: 1.18.15 Severity: minor Hi, when building the piglit package, the dpkg-shlibdeps invocations take upwards of 30 minutes (on an i7, building inside a tmpfs). Most of the time seems to be spent spawning several thousand instances of dpkg-query. Is there a way to speed this

Bug#840308: dpkg: extraction of additional orig archives into nested subdirectory

Package: dpkg Version: 1.18.10 Severity: wishlist Hi, I have several packages that use additional .orig archives for program modules, but these are almost always expected in a nested subdirectory for the package build, e.g. "modules/foo". It would be nice if there was a way to ship this as a

*** SPAM LEVEL 4.823 *** dpkg-shlibdeps: Semi-private symbols

Hi, In #712903, a symbol not intended as public is used by a dependent library. The symbol appears to be exported for the benefit of other libraries built from the same source, so it cannot be easily hidden, but I wonder whether it would make sense to have a mechanism that allows dpkg-shlibdeps

Bug#591522: dpkg-shlibdeps still fails when cross-compiling

Hi, On Tue, Aug 03, 2010 at 04:01:48PM -0400, Loïc Minier wrote: I wonder whether it makes sense to look into /usr/lib at all when cross-building? Not really, I think. If that's not an option, I think the routine checking the format of executable could run the cross-objdump and if it

Bug#591522: dpkg-shlibdeps still fails when cross-compiling

Package: dpkg Version: 1.15.8.2 Severity: normal Hi, while using the target objdump is a Good Thing(tm), it uncovered another bug: for dependent libraries, the host's version is passed to the target objdump. While this looks like a regression as builds that used to work now fail, it isn't,

Re: (not) simplifying dpkg-shlibdeps with readelf

Hi, On Thu, Apr 29, 2010 at 11:24:35AM +0200, Hector Oron wrote: I see no reason why embedded platforms can't use ELF.  ELF is very common in the embedded world even entirely apart from Linux. There is some effort to move from bFLT to something called FDPIC ELF, which is basically ELF with

Bug#558095: dpkg: please accept :native multiarch qualifier in build dependencies

Package: dpkg Version: 1.15.5.2 Severity: wishlist User: debian-embed...@lists.debian.org Usertags: multiarch-cross Hi, We would like to allow people to prepare their packages for cross-compiling. Most functionality is already in place, however we are still lacking a way to distinguish between

Bug#539038: please add support for ad-hoc architecture definitions

Package: dpkg Severity: normal Hi, any news on this? Simon -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-2-amd64 (SMP w/2 CPU cores) Locale: LANG=ja_JP.UTF-8,

Bug#533916: C++ symbol mangling difference between arches

Hi, On Sat, Jun 27, 2009 at 09:23:29AM +0300, Modestas Vainius wrote: While it is a good idea worth consideration but I think demangled symbol names are somewhat too ambiguous to be used in general. See below: [Examples] Not a problem IMO -- we need a new package name anyway if gcc's ABI

Bug#534831: wrong quotation marks in German translation

Package: dpkg Version: 1.15.2 Severity: minor Tags: l10n Hi, dpkg occasionally prints the warning dpkg: Warnung: veraltete Option »--print-installation-architecture, bitte verwenden Sie »--print-architecture« stattdessen.« The correct quotation marks for German are „quote“ or «quote», the

Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain

Hi, On Thu, Mar 12, 2009 at 07:54:49PM +0100, Hector Oron wrote: install anything but libraries and headers into /usr/triplet -- so I don't think there is a pressing need to replicate a filesystem hierarchy standard below a triplet directory. That is what GNU people expect when building

Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain

Hi, , since they have entirely different objectives Not entirely different - the objective for the packaging tools is actually the same, to have packages install cleanly without changes on systems with a different architecture triplet. I'm not sure this can be achieved at all, as we still

Bug#457371: dpkg: please add the DEB_VARIANT build environment variable

Package: dpkg Version: 1.14.12 Severity: wishlist Tags: patch Hi, the attached patch adds a new variable DEB_VARIANT to the build environment, which can be used to build different binary packages out of the same source package in different circumstances. The most obvious application would be

Bug#398625: adapted patch against current dpkg

Package: dpkg Version: 1.14.7 Followup-For: Bug #398625 Hi, I have written a new implementation of the patch proposed earlier, against the current shell script. This patch tries to address all the concerns raised so far, however it introduces some ugliness in doing so: behaviour depends on the

Re: Bug#229357: Can we require build-arch/indep targets for lenny?

Hi, Frank Lichtenheld schrieb: 3) Autodetection My approach would be to have the autobuilders use build-arch, and if that fails within 60 seconds, clean and build. If build-arch is not implemented, it fails rather quickly, so we use build and make a note in the build log. Later, one can

Bug#440094: dpkg-dev: allow specifying the source version explicitly

Hi, Guillem Jover wrote: What you describe is a binNMU but with a different suffix. Maybe we could come up with a generic syntax for binNMU-style versions, which could include backports and the like. That would be difficult. For example, for my cross-toolchain backports I use ~debian4.0+b1

Bug#229357: Can we require build-arch/indep targets for lenny?

Hi, Andreas Metzler wrote: --- Somehow make dpkg-buildpackage -B make use of the build-arch target if present. Either by detecting it automatically or by something like #229357. --- The entire issue circles around not being able to reliably detect whether the target

Bug#229357: Can we require build-arch/indep targets for lenny?

Hello, Goswin von Brederlow wrote: The seconds part requires that tools like sbuild and pbuilder know beforehand if build or build-arch will be used. For packages that do not implement build-arch, it is acceptable to call the build target with only B-D installed, because that is the way the

Re: Secret changes for binNMUs

Hi, Henrique de Moraes Holschuh schrieb: We really need another substvar with different semantics. http://lists.debian.org/debian-devel/2002/09/msg01251.html Simon signature.asc Description: OpenPGP digital signature

Bug#35691: dpkg: New package dependency: affects

Package: dpkg Version: 1.4.0.34 Severity: wishlist I'd like to propose a new dependancy type which could possibly be described best with the keyword affects. The problem behind this is that with slink, many packages that register new mimetypes do not depend on mime-support, and thus get

Bug#35691: dpkg: New package dependency: affects

On Wed, 7 Apr 1999, Santiago Vila wrote: Yet another thing could be done: rewrite the install-mime mechanism and convert it into something like the menu system. The menu system does not have this problem, because it collects the menu entries of each package on the background. The menu

Bug#33991: Automatic library install/deinstall

Stephane Bortzmeyer wrote: My suggestion on how to achieve this would be a new installation request: Install if other packages depend on it, remove otherwise. This could be the default value for just about any package starting with lib*, because they seldom add functionality to the system

Bug#33991: Automatic library install/deinstall

Package: dpkg Version: 1.4.0.33 Severity: wishlist When I cleaned up my disk of stale files, I found out that I had just about 100MB of unneeded libraries floating around, and thought it would be nice if dpkg could remove all the libraries that are no longer needed together with the package I