Re: Debug packages cluttering the archive
Joey Hess <firstname.lastname@example.org> writes:
> Josselin Mouette wrote:
>> The most obvious solution I can come up for this issue is to build a
>> separate tree with DEB_BUILD_OPTIONS="noopt nostrip", at least for i386.
>> That means having a dedicated machine that would be used to run a buildd
>> for that. Unfortunately, I don't have such a machine, and I don't know
>> of an available i386 project machine.
>> Are there some people here who'd be interested, or who could point me to
>> available resources? If not, do you have other ideas to make debugging
>> packages easily available?
> My feeling for some time has been that we should introduce a separate
> section in the archive, or a separate archive and come up with the
> infrastructure to upload -dbg packages to there, with separated
> debugging symbols in them (see dh_strip). This could be done for nearly
> all binary packages, not just libraries. Then people who want all the
> -dbg packages available can just add an apt line and install them at
The packages could end up in main-dbg, contrib-dbg, non-free-dbg. The
dpkg-dev package could be patched to put -dbg packages there
automatically and Katie would just follow the changes file. Or
packages could just change their control file (alowing for some test
packages to do it first).
Alternatively debug packages could be in binary-<arch>-dbg and the
dpkg/apt multiarch patches can be used to include/exclude that
tree. dpkg-dev needs some patching to allow multiarch uploads (uploads
with debs for more than one arch) but thats on the TODO list anyway.
This would have the advantage that SCC would allow to mirror the debug
packages only to some mirrors, e.g. only an eperimental mirror.
> This could be done with varying levels of support in the official
> archive. Ideally we could just upload -dbg packages and have katie split
> them out into a separate section and generate Packages files for that.
If dpkg-dev mangles the architecture or section to *-dbg then all
katie needs is those extra archs/sections in the config file. So
adding support to the software would be trivial. Convincing ftp-master
might be the problem.
> However like the data section I don't know if this is likely to ever
> happen, very few people are able to set it up. It would be nice if we
> could set up a third party site first that collects the packages, but
> it's hard to do because ideally you want to get -dbg packages from the
> autobuilders too, and you don't want them to hit the regular archive.
> The approach that seems IMHO to be most likely to be doable is to modify
> katie to ignore the -dbg packages in Incoming, not add them to the main
> archive, and shunt them to a holding directory, and then set up a separate
> archive to hold them, either on a debian machine or a debian.net machine
> and tie this in so it gets new -dbg packages from the holding directory.
That sounds more complicated then just alowing them in the normal way
as extra arch or section.