Re: Bug#478295: Sha1 and sha256 in .changes and .dsc file
On Tue, 29 Apr 2008 22:24:12 -0700, Russ Allbery <rra@debian.org> said:
>> 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?
> Oh, no. I think it's fine to add things to dpkg without adding them
> to Policy. We may have to test things for a while to be sure they
> work. I just think that after they've been in dpkg for a while and
> won't be changing further, we should take the specification up a level
> of formality and put it into Policy, since at that point it's more
> than just a dpkg feature and is now something the project can rely on.
OK. We should get a sign off from dpkg folks to ensure they are
on the same page as the policy folks about which bits of the API are
features the project depends on and has a reasonable expectation of not
changing.
> If there are fields that are solely internal to dpkg, I don't think we
> should have them in Policy. But if other software needs to interpret
> the fields and take appropriate action, I think the *current* division
> of documentation puts a lot of that material into Policy and people
> are used to looking in Policy for those details.
> It's possible that in a comprehensive rewrite we'll end up wanting to
> separate the field specifications out into a different document or
> handle this differently. I don't want to close the door for
> rethinking this entirely down the road. But right now, I think that
> people do look in Policy for this information and are surprised that
> it's not there, and I think that adding, for example, Homepage was the
> right thing to do.
I would much rather we start thinking of moving these things
into a separate section, if not a separate document, in order to let
people know what bits are not going to be policy anytime soon.
> The key for me is whether other software is relying on the existence
> and format of those fields. For example, I don't see a need to
> document substitution variables in Policy since they're really a
> feature of dpkg-gencontrol and software that looks at Debian packages
> doesn't use the substvars. They're part of the dpkg interface for
> creating packages. But the Vcs-* headers and the Checksum-* headers
> are used by other software apart from dpkg and are part of the public
> specification of a Debian source package or *.changes file.
I think I agree about the Vcs-* headers, but not yet about the
Checksum-* headers (too new to be in policy yet). For me the fact that
a few infrastructure programs need to look at some of these fields is
not really enough; since the infrastructure programs are well known,
few in number, and can and should be changed in lockstep (perhaps evern
staged and uploaded together with a new dpkg).
> I think that we're getting to the point now where if dpkg changed the
> contents of the Checksums-* fields, that would be a serious bug. Of
> course, there's no such thing as a bug that would cause us to release
> lenny without dpkg. :) But I think it would be a bug that would have
> to be fixed for the release.
But if the old format were in policy, it would not have been
dpkg that was fixed, but the policy document. I mean, dpkg is being
accepted in without fixing the checksums; and that to me signifies that
the checksum field is not policy materiel.
> I do think that the dpkg team should have a final say in that, though,
> and if they say that they may still change Checksums-* without going
> through a formal change process, we should hold off.
>> Anything that would automatically be accepted, and merely cause a bug
>> in policy until it is changed, does not belong in policy.
> Agreed.
>> 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.
> Agreed.
> But in this case, I think we do test new features in Debian in dpkg
> first, and then after they've proven to work and are stable, they
> become Policy.
>> 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.
> Well, I think to be consistent we should either include Checksums-* or
> remove Files, which is already in Policy. I personally think it's
> good to have the section on Files since other software can then be
> written to verify checksums on packages following the specification in
> Policy. But I suppose I can see the argument that both Checksums-*
> and Files are details to be worked out betweek dpkg and dak.
Right. I would prefer to remove Files, really, but if we keep
it, and include Checksums, I think we should move both to a separate
subsection with footnotes to the effect that these are more likely to
be informative and documentation, not normative policy -- unless dpkg
folks sign off to not having these changed in the future.
>>> 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.
> Definitely agreed.
manoj
--
If you had any brains, you'd be dangerous.
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: