Bug#1009300: marked as done (dpkg: allow symbol files to be excluded from install)

This is a multi-part message in MIME format...

------------=_1780972621-2573971-0
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

Your message dated Tue, 9 Jun 2026 04:36:11 +0200
with message-id <[email protected]>
and subject line Re: Bug#1009300: dpkg: allow symbol files to be excluded f=
rom install
has caused the Debian Bug report #1009300,
regarding dpkg: allow symbol files to be excluded from install
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


--=20
1009300: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D1009300
Debian Bug Tracking System
Contact [email protected] with problems

------------=_1780972621-2573971-0
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Received: (at submit) by bugs.debian.org; 11 Apr 2022 08:13:57 +0000
X-Spam-Checker-Version: SpamAssassin 3.4.2-bugs.debian.org_2005_01_02
	(2018-09-13) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-120.8 required=4.0 tests=BAYES_00,DKIMWL_WL_HIGH,
	DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FROMDEVELOPER,
	HAS_PACKAGE,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE,TXREP,
	T_SCC_BODY_TEXT_LINE,USER_IN_DKIM_WELCOMELIST,USER_IN_DKIM_WHITELIST,
	XMAILER_REPORTBUG autolearn=ham autolearn_force=no
	version=3.4.2-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 10; hammy, 97; neutral, 35; spammy, 1.
	spammytokens:0.947-+--H*r:bugs.debian.org
	hammytokens:0.000-+--H*M:reportbug, 0.000-+--H*MI:reportbug,
	0.000-+--H*x:reportbug, 0.000-+--H*UA:reportbug, 0.000-+--H*F:U*ansgar
Return-path: <[email protected]>
Received: from tsukuyomi.43-1.org ([116.203.33.193]:43166)
	by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <[email protected]>)
	id 1ndpBN-0000qt-AP
	for [email protected]; Mon, 11 Apr 2022 08:13:57 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=debian.org;
 [email protected]; q=dns/txt; s=2020.ansgar.user; t=1649664832;
 h=content-type : mime-version : content-transfer-encoding : from : to
 : subject : message-id : date : from;
 bh=Q2Ubhbm1Q/75AGc8jvLtmLX20Kl4MupENmWY4kryBg8=;
 b=AewnAeCHaoq65rEPZH+pjRkUoXJtgkvNuNz8Is0UDffOk3KoNskOrq8mJSouWWJeup9Jz
 IKWhN4QIa+lzmRiOEjrINv53bNkgCiJwQEXvgCMwoCdHvM5M7Na3WSFFGxBDZLGrdiHFBV6
 NnYLizBBU3ufg4cA3bA7JH5UdeOo3zUcjEiSIIZi7yJCLDuPGIgrrQftVWTWatwViEvO9ie
 OmUvFMA1QjA05hEhcRdE5rYEq9AYI3LPM+RmiSna5a0OZzCnJIOCK3HWqpf7TpheX13shI6
 tZL9hjdpq8hEgZljGnST09zPjFib6llwBjc+7osDhed3Gam8qSVESjZSGmRw==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Ansgar <[email protected]>
To: Debian Bug Tracking System <[email protected]>
Subject: dpkg: allow symbol files to be excluded from install
Message-ID: <164966483226.355462.14488538584353025441.reportbug@benzaiten>
X-Mailer: reportbug 11.4.1
Date: Mon, 11 Apr 2022 10:13:52 +0200
Delivered-To: [email protected]

Package: dpkg
Version: 1.21.7
Severity: wishlist

Someone wondered on IRC why we ship symbols files in shared library
packages instead of the associated -dev packages and noted that they
take 1% of disk space for a fresh debian:sid docker container (and
probably more on the -slim variant of the container).

It would be nice if it was possible to exclude symbol files from such
environments. This could mean:

 - Ship them in the -dev package instead.

 - Ship them in a well-known location in /usr (they are not variable
   state data after all); this would allow the regular exclusion
   mechanism already used by -slim images to be used here as well.

 - Or both.

Ansgar

------------=_1780972621-2573971-0
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Received: (at 1009300-done) by bugs.debian.org; 9 Jun 2026 02:36:14 +0000
X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02
	(2024-03-25) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-110.5 required=4.0 tests=ALL_TRUSTED,BAYES_00,
	DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FROMDEVELOPER,
	HAS_BUG_NUMBER,SPF_HELO_NONE,SPF_NONE,USER_IN_DKIM_WELCOMELIST
	autolearn=ham autolearn_force=no
	version=4.0.1-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 45; hammy, 150; neutral, 320; spammy,
	0. spammytokens: hammytokens:0.000-+--Hx-spam-relays-external:36ff,
	0.000-+--H*r:36ff, 0.000-+--H*RT:sk:master., 0.000-+--H*RT:216,
	0.000-+--H*RT:36ff
Return-path: <[email protected]>
Received: from master.debian.org ([2001:41b8:202:deb:216:36ff:fe40:4001]:39172)
	by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256)
	(Exim 4.96)
	(envelope-from <[email protected]>)
	id 1wWmK6-00AnYE-1p
	for [email protected];
	Tue, 09 Jun 2026 02:36:14 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org;
	s=smtpauto.master; h=In-Reply-To:Content-Type:MIME-Version:References:
	Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-Transfer-Encoding:
	Content-ID:Content-Description;
	bh=U/MwFz47zxAz7rfI1K6/yrkrBdpOo4SLfLQWF2OXVCE=; b=t6blFczXXAzXirfGlCjRG8Agt4
	6+D7BMhlc73rB1ejLtL74BFfD6gEZgJCTPcLhwESCyCCylTztfuwpZ1xJfwts2z7Hbyxq5Vh4UP2H
	L2r801xA/Q1qLOM77L7C1UMQawHkpeTKkfrtVW9IK+HDY0DRA+W3G8aBm7S4PxNa7aSGQoseqV5D7
	RYHqNPIHmmhRnxLT+ulfreHakuYs8IbZjubRJEGfFDf5CxI93Tzln/mWxZ8dLqKw41bn4POgGnIQd
	TYV0QmyDhx93ryT1VOsqOLKT+54YT26RVSageejXFr03V7impdoa5dfLhBaVB9AWcuw0LjgGbX0Pr
	nTDJogGg==;
Received: from guillem by master.debian.org with local (Exim 4.96)
	(envelope-from <[email protected]>)
	id 1wWmK5-00FOpX-01;
	Tue, 09 Jun 2026 02:36:13 +0000
Date: Tue, 9 Jun 2026 04:36:11 +0200
From: Guillem Jover <[email protected]>
To: [email protected]
Cc: Ansgar <[email protected]>
Subject: Re: Bug#1009300: dpkg: allow symbol files to be excluded from install
Message-ID: <[email protected]>
References: <164966483226.355462.14488538584353025441.reportbug@benzaiten>
 <164966483226.355462.14488538584353025441.reportbug@benzaiten>
 <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email protected]>

On Wed, 2022-04-13 at 13:36:45 +0200, Guillem Jover wrote:
> On Mon, 2022-04-11 at 10:13:52 +0200, Ansgar wrote:
> > Package: dpkg
> > Version: 1.21.7
> > Severity: wishlist
> 
> > Someone wondered on IRC why we ship symbols files in shared library
> > packages instead of the associated -dev packages
> 
> While there is in theory no technical limitation why these could not
> be shipped in -dev packages, as the tools care about only explicitly
> linked shared libraries (so if a transitive shared library does not
> have shlibs/symbols files, that should not be a problem if these are not
> present on the system). The problem is that the tooling needs to be
> able to find these files, and it goes from object SONAME declaration
> to shared object on disk, then looks for the package owning that file,
> and then looks for the shlibs or symbols present in that package (either
> from the system or package build directories).
> 
> (This should probably be documented somewhere explicitly, as I did not
> see anything obvious neither in dpkg docs nor the Debian policy manual.)
> 
> > and noted that they
> > take 1% of disk space for a fresh debian:sid docker container (and
> > probably more on the -slim variant of the container).
> 
> I just checked (OOC) and f.ex. on the current sid-slim variant it
> seems to be around 1.77%. The actual size of these files there is
> 1.6 MiB (according to du -sch). After a quick look I see either trivial
> targets that would more than offset that, f.ex.:
> 
>   $ dpkg -P e2fsprogs libext2fs2 mount gcc-9-base
>   $ rm -f /var/cache/debconf/*.dat-old
>   $ rm -f /var/cache/debconf/templates.dat
> 
> Or other more localized/focused things like there being both libpcre2-8-0
> and libpcre3, or (libcrypto + libssl) + (libhogweed + libnettle +
> libp11-kit + libtasn + libidn2 + libunistring + libgnutls), that would
> give way more significant gains (f.ex. getting rid of the GnuTLS stack
> would amount to something like an additional 8 MiB, including
> reduction from the then no longer present symbols files).
> 
> Matthias Klose seems to have implied (in a bug report) to not find
> symbols files for C++ libraries very helpful, so if he'd decide to
> stop shipping them for libstdc++6 (the biggest there), that would be
> an additional 400 KiB reduction.
> 
> Otherwise making dpkg transparently compress such files on the db,
> would reduce its size by 1.1 MiB (with just gzip), which is something
> that I had previously already considered for the old changelog in the
> dpkg db proposal.
> 
> > It would be nice if it was possible to exclude symbol files from such
> > environments. This could mean:
> > 
> >  - Ship them in the -dev package instead.
> 
> While this could potentially be done, it seems to me the amount of
> global effort and resulting properties might not be a very good
> trade-off for the gains of currently less than 2 MiB (or potentially
> around ~500 KiB) of space there.
> 
> Conceptually storing them in either <lib> or <lib>-dev packages can
> be argued to make sense and have good and bad properties.
> 
> Shipping them on <lib>:
> 
>   - They are guaranteed to be kept in sync with the shared object they
>     describe (no requirement for guaranteeing exact version dependencies
>     between <lib> and <lib>-dev, even though this tends to be current
>     practice).
>   - They do not require adding some way to back-reference the <lib>-dev
>     package corresponding to its <lib> (a new control field f.ex.).
>   - They do not depend on the <lib>-dev package being arch:any (which
>     Multi-Arch would require, but that's an optional feature from dpkg
>     PoV).
>   - (There could be external functional reliance on these files being
>     shipped in <lib> packages to extract specific symbol version
>     information, as this can be considered part of the interface.)
> 
> Shipping them on <lib>-dev:
> 
>   - They are shipped in the package that would denote the file might
>     get used, and don't "waste" space in case no building is going to
>     be happening.
>   - The Build-Depends-Package field in symbols files could be somehow
>     simplified into some boolean variant (but not its
>     Build-Depends-Package_s_ counterpart, although both of these are
>     optional, unlike the required new back-reference field in the control
>     file).
> 
> So doing this change seems to me would imply that:
> 
>  - Maintainers (not just debhelper) would need to modify the packaging
>    to move those files to the new package (which has global impact), for
>    a potentially very long-winded transition.
>  - Switching all libraries seems like a rather large undertaking for
>    a potentially ~500 KiB gain TBH. Switching only packages in the minbase
>    set would create a weird packaging oddness and non-uniformity. :/
>  - Regardless of a full or a partial transition, both locations would
>    need to be supported anyway, which would also make packaging a bit
>    more complicated/confusing.
> 
> This seems in contrast to other proposals to reduce the essential set,
> which imply global efforts, but they also imply complexity reduction by
> making f.ex. the bootstrapping requirements smaller, or making
> dependencies explicit to get rid of implied assumptions. Which in this
> case seems to instead end up adding new complexity.
> 
> >  - Ship them in a well-known location in /usr (they are not variable
> >    state data after all); this would allow the regular exclusion
> >    mechanism already used by -slim images to be used here as well.
> 
> They are varying packaging state metadata, like all other stuff stored
> in the dpkg database. The excludes used, all seem for non-functionally
> altering files anyway. So excluding these files would render these
> images not usable as bases for build containers.
> 
> (Not to mention the additional complication of having to encode these
> pathnames in a way compatible with the dpkg db so that f.ex.
> Multi-Arch can be handled correctly, or whatever new requirements
> might be coming along, w/o needing to encode the location format
> somewhere else.)

I've now documented locally the expected location and part of the
rationale in the deb-symbols(5) and deb-shlibs(5), will be included as
part of my next push. Otherwise I don't see anything else to do
for this request, thus closing.

Guillem
------------=_1780972621-2573971-0--