Re: Bug#478295: Sha1 and sha256 in .changes and .dsc file
On Tue, 29 Apr 2008 09:39:40 -0700, Russ Allbery <rra@debian.org> said:
> Manoj Srivastava <srivasta@acm.org> writes:
>> On Mon, 28 Apr 2008 22:14:18 -0700, Russ Allbery <rra@debian.org>
>> said:
>>
>>> Policy is the only formal documentation we have right now of the
>>> control fields in a Debian package, so I think there's at least a
>>> prima facie argument for adding a specification for any new fields
>>> to Policy, at least unless that documentation is split off to some
>>> other source. I don't know of any other documentation that covers
>>> all the recognized control fields.
>>
>> Even policy does not. Where is Vcs-Browser and VCS-{Arch,Git,SVN,CVS}
>> et al defined? Not in policy, for they do not need to be: even
>> though they are entered in directly by package maintainers.
> That's actually on my to-do list. I think that belongs in Policy as
> well (particularly the non-Browser headers, which are used for
> interoperability within the project -- see debcheckout and
> svnbuildstat, for example).
In that case, we need to have a discussion with the dpkg team to
determine which parts of the format are considered public interfaces,
and will not be changed without requiring a formal change process and a
transition plan, and which portions they can just change.
Do you honestly think that the chnages to dpkg should have
been kept out, until they managed to get policy changed? That dpkg
would have been kept out of lenny until they fixed dpkg not to have the
interface mentioned in policy?
If you think that changing something would keep dpkg out of
lenny with a serious bug, by all means include that bit in policy.
Anything that would automatically be accepted, and merely cause
a bug in policy until it is changed, does not belong in policy.
Stuff in policy should be things that if they are not adhered
to, keep a package out of testing. If things can be changed, and
immediately cause a bug in policy when the change is uploaded, do not
belong in policy. They belong in documentation.
Do changes in GCC cause the ISO/IEC9899 to be amended?
>> So the argument that no other documentation for dpkg exists is not
>> satisfactory, and it flies in the face of trying to fight policy
>> bloat: I would rather policy was a minimal document that only
>> contained things that a maintainer _had_ to know. Policy should be,
>> err, policy, and not merely documentation. If we lack documentation,
>> the answer should be to create the documentation, not to bloat
>> policy. This should be a bug against dpkg, really, if the behaviour
>> of dpkg and friends is not documented in detail.
> Hm. I would argue that knowing everything that goes into a *.changes
> or *.dsc file is something that a maintainer at least should, if not
> must, know. For example, I'd expect that to be a topic of NM.
People need to know more about Debian and tools than just the
technical policy (which, for example, does not over things like GPG
keys and such); so merely these are things one needs to know is again
not sufficient. Sure, people ought to know what lives in *.changes;
but it is not required for packaging, and yes, changing how programs
are involved may break other programs (things broke when flex changed,
for instance), but that does not make it policy materiel either.
What dpkg-genchanges produces is not needed of packaging, and is
not needed for interoperability, apart from a small smattering of
infrastructure packages, which do not need the weight of policy to
enforce.
> That doesn't necessarily mean that it needs to be in Policy, but on
> the other hand if we created dpkg documentation that contained
> comprehensive documentation of all control fields, that would to a
> large extent duplicate the existing Policy document. And I can't
> imagine wanting to move most of the control fields out of Policy.
I can. If they are not policy, but documentation, they should be
removed from policy. We have long been waiting for such a cleanup of
policy.
>> It is not as if writing current behavior into stone and preventing
>> any changes is a good thing for the project: the only reason for
>> writing an API down in policy is so that it does not ever change
>> (future versions of the package should adhere to the standard, and
>> not innovate: no one wants, for example, wild and wooly innovation
>> from gcc and libc -- and policy should, in my view, be close to a
>> standards document). If the behaviour is indeed subject to change,
>> and is not a standard API or behaviour that should be preserved by
>> future dpkg authors, then what we want is documentation, not policy.
> This I do agree with. I don't think it belongs in Policy until it's
> finalized and fairly unlikely to change.
We need the dialogue with dpkg authors to determine what parts
of packaging related things in policy are standards, that dpkg authors
cannot change without a transition plan and a change document, and an
update of policy _first_, and what parts need to be in dpkg
documentation, and removed from policy.
manoj
--
Time is an illusion perpetrated by the manufacturers of space.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: