Re: Automatic Debug Packages
On Wed, Aug 12 2009, Emilio Pozuelo Monfort wrote:
> There will still be a repository with all the .ddebs.
And aptitude and dpkg will know how to install ddebs, somehow?
and synaptic, etc?
> But also we will have a share that will ship all the debugging symbols
> in a build id file hierarchy structure (so something like
> .build-id/xx/xxxxxxx.debug). You can mount it in your system and use
> it as if you had installed every -ddeb available in the
So all debugging has to happen online? Many places have a
prohibition against mounting a file system from outside the firewall,
though installing packages that have been vetted is permissible
> Furthermore, if disk space permits it, we will provide symbols for
> more than one version (i.e. not only the current package in the
> archive, but maybe the last three or whatever we can do), since build
> ids permit it.
With packages, mirrored repositories may have a different
retention policy, and not rely on the packages one has installed
disappearing off the remote filesystem.
The system you propose works great for the use case you have
envisaged: Debugging on a low security instllation with always on
broadband connection to the network; but surely that is not the only
model we provide.
I am also wondering about the obstacles placed in the path of
packages that will not be covered by the automated system. While we
were talking about generating .debs, that was some work, but not any
different from creating a package. Now, in order to create a hand
crafted ddeb, what does one do? Add a nerw package to debian/control,
build it, rename the package, edit ./debian/files before
dpkg-genchanges is called -- this is more complex than just calling
dpkg-buildpackage and be done with it.
So I am wondering if the selction by package name is not good
enough, and whether we really need selection using *.ddeb$ --
/.*-ddeb_.*\.deb$/ is not that much more complex a regular expression,
and it brings with it the ability to manually create the debug symbol
packages easily, using dpkg-bvuildpackage.
I too am wondering if we should defer the polivy change until
the details get shaken out with a partial deployment of the scheme.
"Don't tell me I'm burning the candle at both ends -- tell me where to
get more wax!!"
Manoj Srivastava <email@example.com> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C