[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Automatic Debug Packages

Russ Allbery wrote:
> Emilio Pozuelo Monfort <pochu27@gmail.com> writes:
>> Russ Allbery wrote:
>>> It sounds like listing them only in *.changes but not in *.dsc or
>>> debian/control may be the easiest approach.
>> Indeed, for the automatic-not-listed-in-debian-control ones. The others
>> would be listed everywhere, but that is okay.
> Yes, agreed.
> Okay, to summarize what I think we've generally agreed on:
> * Packages containing separate debugging symbols will have a dedicated
>   package namespace, but that namespace will not be *-debug or *-dbg.
>   We'll instead create a new one for this purpose.
> * These packages are normal Debian packages with normal package metadata,
>   but will generally have a symlink in /usr/share/doc/<package> pointing
>   to the package for which they provide debugging information.

We haven't agreed on whether there should be one ddeb per source or per binary
package, so I would leave this still opened.

> * They will go into a separate "debug" archive area, so the Section of
>   such packages will be debug/<foo> where <foo> is the section of the
>   corresponding binary package for which they provide debugging data.

Not sure about the archive area bit. What I talked with the ftpmasters was that
they would be in a totally different archive, so instead of
"ftp.debian.org/debian unstable main", you would have something like
"ftp.debian.org/debian-debug unstable main". I don't think that's an "archive
area" in Policy terms.

> * Those packages must be listed in *.changes like any other packages that
>   are part of an upload.  They may or may not be present in debian/control
>   and in *.dsc depending on the mechanism the package maintainer uses to
>   generate them.

I guess that doesn't imply they need to be listed in Binary and Description, but
that Files and Checksum-* are enough? If so, perfect.

> * The detached debugging symbols may use either the id or the debuglink
>   mechanisms -- see Manoj's message for a summary.
> Open questions:
> * Can we limit this package namespace to *only* detached debugging
>   symbols, not all the other sorts of debugging packages that people
>   create with special compiler options or optional code features?

Why should we limit it? There currently are about 85 python -dbg packages. A lot
more could be added. Why limit .ddebs to ELF binaries? Same for mono, I've added
a (trivial) patch to dh_clistrip to support ddebs. We would gain support for
many packages with exactly zero changes (or just a change to remove the -dbg
where they exist). What are the benefits of such a limitation?

> * What about contrib and non-free packages?  Do they just lose here?

If it's legal to ship debugging symbols for them, I can't see why we couldn't
support them normally.

> * Can we require a one-to-one correspondance between binary package names
>   and debug package names that provide symbols for that binary package?  I
>   think we should; I think it would make the system more straightforward.

I guess the Packages file could grow a "Has-DDeb: yes" line (or the Sources file
if we go for one ddeb per source package). Or we could have a different file for
this similar to the Maintainers one, I guess, since the trend seems to be to
split those files nowadays.

> At some point, someone should probably open a Policy bug to track this
> discussion and the resolution.

I would be happy to do that. I guess it can wait a bit until we have a bit more
consensus, or should I do it now and update it with whatever conclusions we reach?


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: