On Fri, Aug 14 2009, Steve Langasek wrote:
> Er, the point is that you've plucked this "apt-get debug" out of the > *Ubuntu* spec, <https://wiki.ubuntu.com/AptElfDebugSymbols>; that spec > is considered implemented, Ubuntu doesn't have such a debug command, > and Emilio's proposal at > <http://wiki.debian.org/AutomaticDebugPackages> makes no mention of > implementing this. Yet your messages come across as though you think > it's a foregone conclusion that this command is going to be > implemented. Well, I was nort looking at the Ubuntu spec at all, but I might have been mislead into a false sense of security: From: Philipp Kern <tr...@philkern.de> Subject: Re: Automatic Debug Packages Message-ID: <slrnh87q12.7jj.tr...@kelgar.0x539.de> >>> This use case is IMHO implicitly addressed by making them >>> downloadable and installable on the local system. From: Emilio Pozuelo Monfort <poch...@gmail.com> Message-ID: <4a84127e.1050...@gmail.com> >>>> 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. Given that assurance that aptitude and synaptic will know how to install ddebs, I said that satisfies my concern. I don't actually care what the command keyword used is, it may well be aptitude Avara-Kadavara foo-debug for all I care. Are you saying that the assurance had no merit? > So given that specification of apt-get commandline options *definitely* > doesn't belong in Policy, and no one has agreed to implement 'apt-get > debug', I think you might want to make your concerns about the package > management tools explicit. Well, before this issue is nailed down and writ into policy, the use cases for on-line webdav/nfs/share based debugging (including issues of where things are cached, how long they are cached, whether the bandwidth requirements make it infeasible), as well as the download debug packages method details need to be hammered out. I do think that we need to have some kind of broad architecture of the solution in place for the common use cases before we can actually craft policy, and so far, I am very fuzzy about the aolution architecture. manoj -- In order to discover who you are, first learn who everybody else is; you're what's left. 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-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
