Bug#478295: Sha1 and sha256 in .changes and .dsc file
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).
> 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.
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.
> 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.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: