Manoj Srivastava <[EMAIL PROTECTED]> writes: > On Tue, 29 Apr 2008 09:39:40 -0700, Russ Allbery <[EMAIL PROTECTED]> said:
>> 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. Agreed there. I think they're ready for Policy precisely because I think they're stable and enough things are already using them that they wouldn't be changed without that process even if they weren't in Policy. > 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. 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. 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 realize that Debian is a little odd compared to a pure IETF-style standards world in that Debian requires that you use dpkg to generate packages and doesn't fully specify every detail of what dpkg does in Policy to allow a completely separate implementation. So it's a bit harder to draw this line than it would be for, say, a network protocol where implementations have to be permitted to be entirely different. > If you think that changing something would keep dpkg out of > lenny with a serious bug, by all means include that bit in policy. 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. 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. > Do changes in GCC cause the ISO/IEC9899 to be amended? This is where the above bit about dpkg being required comes in. GCC isn't in that same situation; ISO C99 is supposed to be comprehensive, sufficient to write a completely separate independent implementation. There are aspects of the Debian package format (such as the details of how you put things together with ar and tar) that Policy does not document and says that you just have to use dpkg. 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. >> 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. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
