Re: Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)
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?
> B) Use ".ddeb" (i.e. with an extra "d").
What where the motivations for using a different extension? 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.
Assuming that any issue with debug .deb:s is fixed in the tools, is
there any remaining reason to use .ddeb:s?
> 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.
> > - 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_*»)?
> > - This is *currently not working* since dpkg-genchanges errors out
> > on the auto-generated .deb files.
See above. :)
> > B) means that .ddebs can be special cased on filenames rather than on
> > section (like udebs). Furthermore, there might be a lot of things
> > that do not need to support .ddebs at all.
Personally I think it breaks expectations, from muscle memory:
# dpkg -i *.deb
to many tools that might process debs and expect them to have that
extension, which of course could be fixed but we have to take into
account tools outside of the Debian archive.
> > - Downside is that adding support is a manual extra step for many
> > tools, that (besides the filename) would otherwise be able to
> > handle .ddebs immediately.
For example dpkg-scanpackages can be told to use a different package
type, but it cannot be told to recognize multiple package types for
the same invocation. I guess in this case you can cat the result, but
still:
$ ( dpkg-scanpackages . ; dpkg-scanpackages --type ddeb . ) >Pacakges
this would imply either fixing the tool or going around and changing lots
of scripts for custom repositories.
> > - On the plus side: dpkg-genchanges in Jessie can support this
> > solution immediately with a minor warning.
Sure, immediate deployment is a plus, but I'd rather we'd carefully
consider the consequences of any such decission that might be pretty
hard to reverse course in the future in case we find it to be too
problematic.
> >>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
Reply to: