Manoj Srivastava wrote:
> On Tue, Aug 11 2009, Russ Allbery wrote:
>
>> Emilio Pozuelo Monfort <pochu27@gmail.com> writes:
>>> Manoj Srivastava wrote:
>>>> To recap:
>>>> 1) packages with detached debugging symbols should be named
>>>> ${package name}-${debug suffix}. As a corollary, no ordinary
>>>> packages names may end in ${debug suffix}.
>>> They may be automatically created. They may also be manually created (if
>>> they are listed in debian/control, so for complex packages where they
>>> need some manual work, it can be done).
>> Whether they're automatically or manually created is irrelevant for Debian
>> Policy. Policy describes what the output should be, not what tools one
>> uses to get there.
>>
>> I think the relevant question for Policy is whether these packages will be
>> listed in debian/control in the source package, in Binary in the *.dsc
>> file, and in Binary/Files/Checksums-* in the *.changes file. And I don't
>> know the answer to those three questions from the discussion so far.
>
> Here is my take on this:
> a) helper packages may be extended to created debug packages by
> default, whether or not they're mentioned in control. This means
> that any package rebuilt the next time will get debugging packages,
> even if the maintainer takes no action. Policy should not prevent
> this use case, so requiring that the control file mentions them
> should not be done.
> b) Some upstream packages, even if helper packages are used, might not
> be readily amenable to automated generation of debug packages, and
> manual help might be required. In this category I would also like to
> throw in packages that do not use helper packages; since themanual
> crafting of debug symbol packages is a commonality. These packages
> have the debug packages in debian/control, and htey are built
> normally (either through custoim scripts, or helper packages). In
> this case, the helper should not automatically generate debug symbol
> packages; and thus give us a mechanism to over ride, on a package by
> package basis, the creation of automated debug packages.
ACK
>
> So I think at this point it is premature for policy to decide
> one way or the other about debug symbol packages being mentioned in the
> control file (and dsc and changes).
They should be in the changes file so they are uploaded together with it to the
archive (and so dak can process them). Not saying that should be mentioned in
policy though :)
Having them in the Binary section in the .dsc and Binary and Description in the
.changes files would mean modifying dpkg-buildpackage/dpkg-genchanges for ddebs
not listed in debian/control. However listing them in Files and Checksum-* in
the .changes requires no changes if you add the files to debian/files and use
dpkg-genchanges.
> Another reason is that we should not be accepting any packages,
> even debug packages, in the archive unless we have a check sum match in
> a cryptographically signed file anyway.
Agreed. As per my previous paragraph, having them in Files and Checksum-* would
solve this.
Regards,
Emilio
Attachment:
signature.asc
Description: OpenPGP digital signature