Re: Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)
On 2015-05-03 18:58, Guillem Jover wrote:
> Hi!
>
> On Tue, 2015-04-07 at 22:11:18 +0200, Niels Thykier wrote:
>> A) Use ".deb" (i.e. the regular extension) with a new "section".
>
> Is there any problem with using the existing "debug" section? Or is
> the different section used to distinguish that these are autogenerated
> perhaps?
>
I picked "debugsym" to ensure it distinguished the automatically
generated debug debs from hand-crafted ones while testing it. I am
personally slightly in favour of keeping this as an (extra)
discriminator. That said, I will not object to using the normal "debug"
section.
>> B) Use ".ddeb" (i.e. with an extra "d").
>
> What where the motivations for using a different extension?
I have heard of/can think of two reasons:
* it was to have a trivial discriminator prior to unpacking /
extracting information from the deb.
* backwards compatibility with Ubuntu's setup.
> I can
> see the motivation for .udeb:s as they need to live in a different
> namespace, but that does not seem to be the case for debug debs.
>
Please keep in mind that there /is/ a desire to keep ddebs trivially
distinguishable from regular debs. Among other things, to facilitate
putting ddebs in a separate part of the mirror to avoid inflating the
size of the metadata on the mirror (for users not using ddebs).
> Assuming that any issue with debug .deb:s is fixed in the tools, is
> there any remaining reason to use .ddeb:s?
>
To my knowledge: No - dpkg-genchanges and dak are the only known tools
blocking the use of ".deb".
To be honest, I am not sure about dak, as I have not tried uploading
with an "out-of-band" deb. That said, dak will want to know about them
to avoid an explosion in the NEW queue.
>> On 2015-04-07 21:10, Niels Thykier wrote:
>>> Both have their own advantages and disadvantages. In particular:
>>>
>>> A) means that almost every existing tool will handle the debug debs
>>> like a regular deb (which it is) and will generally work perfectly
>>> out of the box.
>>> - There are a couple of exceptions, but we are limited to something
>>> like lintian and dpkg-genchanges.
>
> I'd happily look into making dpkg-genchanges allow this.
>
Thanks. I tried dpkg from git, which now allows them with only a
warning. I would certainly be interested in having a (long-term)
solution that did not warn about these.
>>> - There will be tools that might want to handle them differently.
>>> Programs like dak and reprepro might want to (support) put(ting)
>>> them in a different part of their repositories.
>
> They could already do that by keying on the Section, no? Otherwise the
> filename is also unique enough to be keyed on («*-dbgsym_*»)?
>
That is my understanding as well. Note that Ubuntu have a few
"manually" generated "*-dbgsym_*" packages (e.g. for the linux kernel).
It is my understanding that these are "in spirit" intended to be
considered regular ddebs. Accordingly, there ought to be no issue in
filtering based on that file name pattern.
> [...]
>>> >From my point of view, I am not strongly attached to one solution over
>>> the other:
>>> * I am slightly preferring A), but I am ready to implement either
>>> solution in the tools, I maintain.
>>> * The difference for debhelper is a single "d" and a section name.
>>> * The change for lintian is larger, but B) is the "heavy" solution
>>> and I already got a "mostly working" patch for that.
>
> Barring any strong reasoning behind B) above, I pretty much prefer A).
>
> Thanks,
> Guillem
>
Great. :) To my knowledge, A) is also the solution that the FTP masters
seemed to prefer.
Thanks,
~Niels
Reply to: