[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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)

"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: