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 > 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 . > 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. manoj -- "Don't tell me I'm burning the candle at both ends -- tell me where to get more wax!!" Manoj Srivastava <sriva...@debian.org> <http://www.debian.org/~srivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org