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? Best, Emilio
Attachment:
signature.asc
Description: OpenPGP digital signature