Re: Bug#478295: Sha1 and sha256 in .changes and .dsc file
Manoj Srivastava <srivasta@debian.org> writes:
> 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.
Yup, I agree with that.
> 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.
Looking over the list of fields, the ones that seem to meet the criteria
for removal to another document are:
Description (in *.dsc and *.changes files only)
Changed-By
Date
Format ("format described in the Policy Manual is version 1.5")
Changes
Binary
Installed-Size
Files
Closes
or basically most of the fields that dpkg generates in *.dsc and *.changes
files but which are not part of the debian/control format and which the
maintainers generally have no or only indirect influence over. Urgency is
a borderline case, although we could drop the control field description
and just focus on the changelog specification (which is, IMO, clear Policy
material).
That raises the question of whether the Policy manual should kick out all
descriptions of *.changes files to another document (and possibly *.dsc
files as well) and focus only on describing the meaning and effects of
debian/control.
Whatever that other document is, I think it should be maintained with
similar rigor to Policy, but then I'm in the camp of thinking that a
detailed specification for the entirety of what dpkg does would be
excellent. Ideally, we should have a specification with sufficient detail
to allow someone to reimplement dpkg from the specification and have it
interoperate. (But this is certainly not something which the Policy team
has the resources to tackle.)
> 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.
Yeah, I see your point.
> 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.
Well, one approach we could take (probably for a future version rather
than the upcoming 3.8.0.0 release) would be to move the *.dsc and
*.changes material, including those fields peculiar to them, into an
informative appendix.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: