Bug#971680: /usr/share/gcc-10/python/ should go in a dev package
On 10/5/20 8:35 PM, Josh Triplett wrote:
> 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?
usually people are used to to install the -dbg packages for debugging. How
would you tell people when to install all corresponding -dev packages?
>>> 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.
agreed for that case. However usually all these pretty printer files are
installed in the autoload location.
Reply to: