Re: Automatic Debug Packages
On Sun, Aug 09 2009, Steve Langasek wrote:
> On Sat, Aug 08, 2009 at 08:33:09PM -0500, Manoj Srivastava wrote:
>> > Manoj Srivastava wrote:
>> >> On Sat, Aug 08 2009, Emilio Pozuelo Monfort wrote:
>> >>> I've documented the .ddeb format in the wiki page [1] ("DDeb Format",
>> >>> which is short since the format is basically that of .debs). Do we
>> >>> really need this to be documented in policy?
>
>> >> Not if that is all that is. So ddebs are just -dbg packages
>> >> renamed to foo_version_arch.ddeb (you do not need ddeb in the name
>> >> since they are called .ddebs.)
>
>> > dpkg doesn't know about filenames AFAICS. So you can't coinstall
>> > foo_1.0-1_i386.deb and foo_1.0-1_i386.ddeb, right? So we do want the
>> > -ddeb suffix.
>
>> If we are going to enshrine ddebs into policy, we might as well
>> teach dpkg about ddebs.
>
> I don't have a strong opinion on whether ddebs should be documented in
> policy, but I certainly don't agree with requiring dpkg to understand
> them as a prerequisite for implementing a general purpose, public
> archive for auto-stripped debugging symbols packages. There really is
Since this is on -policy, I am commenting on when it gains
enough gravitas to be enshrined in policy. Getting things in policy is
also not a pre-requisite for implementing a general purpose, public
archive for auto-stripped debugging symbols packages.
I do have a question: Why is the fact that these are
automatically created relevant?
> no reason for dpkg to treat these packages specially - a simple
> namespace convention imposed by Policy (i.e., reserving package names
> ending in "-ddeb" for use by this archive, which is what has been
> proposed) is sufficient, and requires no changes to dpkg, which is as
> it should be.
Why should it be a leading change in policy? Can't we try out
the experiment, make any changes needed, and then come with the policy
change? If we do not need maintainers to change anything, ans we do not
need dpkg to change anything, why is there a hurry to get this into
policy before it has been implemented and tested?
> I think the .ddeb extension is a red herring. There ought not be
> anything new to teach dpkg, here; the only thing of relevance is that
> there not be namespace clashes between the ddebs and the debs in the
> main archive, and the filename is not relevant to that at all.
So why not just have foo-ddeb.*.deb? This is the kind of thing I
want to see discussed, and alternatives tried for, before we
hard code stuff into policy.
>> So why are we creating a whole new class of packages which dpkg
>> does not know about,
>
> dpkg "knows" about them the same way it "knows" about debs, AFAICS.
Why, then, the .ddeb suffix? Why are these not just .debs, with
a specific naming schema?
>> and which are substantially the same as the current -dbg packages? Is it
>> to just reduce debian/control file bloat? Or to create debug packages
>> whether or not the maintainer cooperates?
>
> To optionally create debug packages without requiring work by individual
> package maintainers.
Why should automatically created debug packages be treated
differently than hand crafted ones? Why shouldn't _all_ debug packages
follow the same naming policy? Is there a reason for this (confusing)
distinction?
manoj
--
"All we are given is possibilities -- to make ourselves one thing or
another." Ortega y Gasset
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: