Emilio Pozuelo Monfort <poch...@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. * 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. * 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. * 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? * What about contrib and non-free packages? Do they just lose here? * 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. At some point, someone should probably open a Policy bug to track this discussion and the resolution. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
