Manoj Srivastava wrote: > 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? Yes, dpkg, apt-get, aptitude and synaptic all work perfectly fine. They don't care about the extension at all. >> 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 >> archive. > > 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 No, we provide it for whoever wants to use it. There will still be an archive with all the packages, so if you prefer that or if you won't have networking when the need of debugging arises, or if you don't like the other way, use the packages. >> 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. As I've said, there will still be a debug archive. I don't see what's the problem with providing *both* an archive and a share, really. If you can't use the latter, that's fine, use the packages. > 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. You can do it the hard way. Or you can tell dpkg-gencontrol how the package should be named with the -n option. It will do the correct thing, and add the correct filename to debian/files. Furthermore, we could expand dpkg-gencontrol to accept a --extension option, so that you don't need to look for the package version and arch. Cheers, Emilio
Attachment:
signature.asc
Description: OpenPGP digital signature