[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Automatic Debug Packages

On 11826 March 1977, Emilio Pozuelo Monfort wrote:

> The proposal is (very briefly) to make dak accept .ddeb packages (containing
> debugging symbols using build-ids), and to then modify helper tools to
> automatically generate them and add them to the changes file. I've written down
> the details in the wiki [2], and I'll appreciate it if you could give some
> feeback. I don't want to trash this completely though, so no drastic changes
> preferred :)

What a long thread, brrr. So lets take the start message of it and reply
to a few points that have been all over in it.

First, the naming:
It is indeed us Ftpmasters who want them named .ddeb. For two reasons -
a simple one is that it makes the handling much easier, if you can match
on *.ddeb$. Another one is that they aren't "real" debs like .deb. They
aren't meant for normal user consumption, but only for special
situations. For most users possibly completly automated and
transparently in the background. Seperating them as .ddeb helps making
it clear it is "something different than what you know from usual debian
packages". More so than a -debug in the name alone.

Also, ddebs should probably be defined in policy as not having
maintainer scripts.

Additionally the naming should include a -$DEBUG, so it will be
$DEBUG should be a string not otherwise used, debug would probably work

Second the storage:
Archive side they will be put into the normal
directories right beside the source and other binaries from the
package. They will, however, not be exported to the public view of the
archive. Instead we will export a second directory which contains them,
which can then be mirrored seperately from mirrors that do want to have

Now, as that will be a seperately exported mirror tree it leaves license
compliance (provide binaries, provide source). Thats discussable - as we
only provide debug symbols/code/whatever_funny_language_uses_for_it we
might not fall below that requirement. Most likely we ensure compliance
by having symlinks back into the normal /debian/ mirror tree of a
mirror, and requiring each mirror to only mirror this if they also have
/debian/. (This was one way the sarge amd64 archive was presented to the
mirrors. Saved some of them quite a lot of space, not needing to
duplicate the source from Debian.)

Contents of a .ddeb:
The contents of a .ddeb should strictly be limited to debugging symbols
- or whatever their equivalent is in other programming
languages/environments. No user needed/runable parts should be there.
Which will keep -dbg packages like the python interpreters in the normal
Additionally a .ddeb must either include a
/usr/share/doc/$package-$debug/ directory or a symlink to a
/usr/share/doc/$package directory of a package it depends on.

Quantity of .ddebs:
Usually there should only be one .ddeb per source. Of course there are
always exceptions from the rule, so Maintainers may chose to have one
per binary package. This should only be taken when the size of the debug
package gets *huge* otherwise. It is hard to set definite numbers here,
but a 5mb package would surely not be a reason to split into two 2.5mb

Other stuff:
Most of the other stuff is not of much concern to us.
As to how the files within ddebs should be named, this isn't an archive
side matter (although I personally favor to put files named after their
build-ids into the .ddebs).

The packages do also not need to be listed in debian/control, if they
follow the "one ddeb per source" general rule. If there are more of them
then they will need to be explicitly defined.
They do *ALL* have to appear in the .changes file uploaded.

bye, Joerg, your FTPMaster of the evening
"Hätten die Affen, von denen wir angeblich abstammen, geahnt, dass durch
die Evolution eines Tages aus Ihren Reihen Politiker entstehen würden,
wären sie auf Ihren Bäumen geblieben und hätten niemals versucht den
aufrechten Gang zu erlernen."
(J. Sheridan, Babylon5)

Attachment: pgpJi6nrapx9B.pgp
Description: PGP signature

Reply to: