On Tue, Aug 11 2009, Steve Langasek wrote:
> But if this is all the more respect you have for your fellow (TC
> members|DDs|human beings), O Peerless and Saintly Policy Editor, then
> perhaps the project should reconsider whether that's a position you should
> hold.
The -vote list is -> that-away.
>
>> 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).
>
> "If we are going to enshrine ddebs into policy, we might as well
> teach dpkg about ddebs."
>
> http://lists.debian.org/debian-policy/2009/08/msg00044.html
>
> That was not a question. But apparently, any statements you've made in
> emails more than a day old are "strawmen" that you're not responsible for.
It was a suggestion. It was not a dictum "do this or the rule
shall not enter policy". The correct response is to point out why there
is no need to teach dpkg anything, or why doing so is suboptimal (the
former applies here).
>> >> 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.
>
> The normal disambiguation rules involve telling someone to stop
> building a conflicting package. If one of the parties is an automated
> build, that doesn't work so well. Either the namespace should be
> clearly reserved, or the automatic build hooks are going to have to
> maintain a blacklist of packages not to act on.
The namespace for packages containing debug symbols out to be
clearly resolved, and separated from the other non-debug-symbol
packages, irrespective of the tools used to generate the debug symbol
package.
The auto-tools would still have to look into debian/control, but
that is an implementation detail.
manoj
--
A man wrapped up in himself makes a very small package.
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-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
