On Mon, Oct 05, 2020 at 12:08:28PM +0200, Matthias Klose wrote: > On 10/5/20 10:39 AM, Josh Triplett wrote: > > On Mon, Oct 05, 2020 at 09:32:28AM +0200, Matthias Klose wrote: > >> On 10/4/20 11:09 PM, Josh Triplett wrote: > >>> libstdc++6, installed on every system due to dependencies, contains > >>> various Python scripts for GDB under /usr/share/gcc-10/python/ . These > >>> scripts should go in a dev package, not in a library package. > >> > >> There's no part in the policy that requires debugging scripts to be part > >> of the > >> development package, and I think it's not very intuitive. There's also no > >> advocated policy if these scripts should be part of a dbgsym package, and > >> there's no debhelper support to add these files to a dbgsym package. So > >> yes, I > >> think the library package is the correct package to have these files. It > >> makes > >> the library package a little bit bigger, but these don't hurt there. > > > > There's precedent for things related to debugging a particular library > > going into the -dev package for that library. For example, > > /usr/share/gdb/auto-load/lib/x86_64-linux-gnu/libpthread-2.31.so-gdb.py > > lives in libc6-dev, not in libc6. > > these were only added later than the libstdc++6 ones, so no precedence.
I mean that it's precedent for putting debug-related things in -dev packages, not that it came before libstdc++6 specifically. Would it be a *problem* to put these files in the -dev package? > > There may be a better place for them, but this seems like a reasonable > > approach. > > > > My concern is that I'm trying to build a minimal Debian-based system, > > libstdc++6 is hard-required because among other things apt depends on > > it, and it's shipping ~132k of Python scripts. > > if that's a minimal system, you probably could use the same technique like > probably removing files in /usr/share/doc. That's a workaround, and it'd be nice if it just needed to cover a few general locations shared among many packages, not individual files from one package.
