Re: Automatic Debug Packages
On Mon, Aug 10 2009, Steve Langasek wrote:
> On Sun, Aug 09, 2009 at 07:37:10PM -0500, Manoj Srivastava wrote:
>
>> >> > 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.
>
> There is a namespace issue here, that falls in scope for Policy because it
> impacts interoperability; if there are going to be limits placed on the
> names of packages in the main archive, that almost certainly *does* belong
> in Policy. And the Policy editors should not be dictating a dpkg
> implementation for ddebs as a precondition, not when that dpkg
> implementation isn't required and doesn't appear to have any backing from
> the dpkg maintainers.
The policy editors may ask for the design to be implemented and
tested, and (gasp) even critique the design, before having it added to
policy. Policy is not the place to shoce in untested/raw design.
And in this case, there seems to be an issue of occams razor:
why should a new file suffix be created when policy based naming wold
not require it in the first place; namespace partitioning can be done
on the package name, not on the filename.
So, please keep heckling from the peanut gallery to a minimum,
please, and assume that policy editors have a modicum of sense when
dealing with their role duties.
>> I do have a question: Why is the fact that these are
>> automatically created relevant?
>
> Because if they're *not* automatically created, there's no namespace
> issue: package name conflicts would continue to be resolved the usual
> way, via ftpmasters and the NEW queue.
Seems like if policy carves out a namespace for debug packages,
it would serve for both automatically generated and hand crafted debug
packages; and it is trivial for the automatic generation not to happen
when there is an entry in debian/control for a debug package already,
as long as there is a naming convention for debug packages.
>
>> 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'm in no particular hurry, myself, but I think the right time to
> reserve package namespace is *before* there are exceptions in the
> archive that have to be dealt with. What with the maxim about Policy
> not making packages insta-buggy, and all.
If policy is going to be creating name spaces for debug
packages, it should be done on the basis of the content or type of
package it is, not because of the tools that created it.
We do not have a
emacs-debhelper_2.3-1_amd64.deb
emacs-cdbs_2.3-1_amd64.deb
emacs-yada_2.3-1_amd64.deb
So as long as there is clarity on what the contents of the package
should be (only detached debug symbols, kept in a standard location, or
something), how they are generated should not matter.
>> So why not just have foo-ddeb.*.deb?
>
> Why not, indeed?
manoj
--
"Oh what wouldn't I give to be spat at in the face..." a prisoner in
"Life of Brian"
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: