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

Re: Automatic Debug Packages



On Mon, Aug 10 2009, Steve Langasek wrote:

> On Mon, Aug 10, 2009 at 11:17:45AM -0500, Manoj Srivastava wrote:
>> > 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,
>
> Yes, and I may critique the quality of your critique.  This doesn't belong
> in dpkg.

        Given that it turns out that the proposed packages are really
 just plain old .deb packages, with the only change being additional
 constraints on content, you are right.


>>         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.
>
> If you were showing a modicum of sense, there would be no need to assume.
>
> For example, not referring to a fellow member of the Technical Committee,
> the constitutional authority on Debian technical policy, as "the peanut
> gallery".

        The word you are looking for is not sense. It is respect.

        You expect respect based on the position you hold -- not the
 arguments you made. I reject the notion that I should make exeptions
 based on the office you hold (in other words, it is OK to call non-dd's
 on the list members of the peanut gallery, but not the
 oh-so-respectable ctte members such).

        Telling me I my argument was incorrect (which it was) is one
 thing, saying that policy team members should not do something that I
 had not actually advocated (I never said that dpkg implementation was a
 prerequisite to adding things to policy --- I just asked why that is
 not the reasonable thing to do first). So, if you again pull a strawman
 argument and proceed to hector a ole in Debian, I shall again call such
 content heckling from the peanut gallery, irrespective of how high and
 mighty the author was.

        Not arguing against the man cuts both ways.

>> >>         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.
>
> That's fair, but it doesn't guard against package name collisions with
> packages built from a *different* source package; so if manually-built
> packages are allowed to use the same namespace, there ought to be a policy
> in place that prevents them from being provided in a way that confuses the
> automated build process.

        Umm, huh? If the name space carved out is foo-debug, or even
 foo-dbg, the only collision I see is a *different* package has a native name
 of foo-dbg and thus collides with the debugging symbols from foo.

        If such packages existed, then not only would they create
 trouble with the current slew of debug packages, they can always be
 resolved by our normal disambiguation rules.

        manoj
-- 
"Pull the trigger and you're garbage." Lady Blue
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: