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 $package-$DEBUG_$version_$arch.ddeb. $DEBUG should be a string not otherwise used, debug would probably work well. 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 them. 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 archive. 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 ones. 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)
pgpp5E43bfWNQ.pgp
Description: PGP signature
