On Wed, 12 Aug 2009 08:22:17 -0500 Manoj Srivastava <srivasta@debian.org> wrote: > > In many cases, wouldn't such a relationship be better expressed by a > > dependency on a package that implemented the new behaviour? Often it's > > dpkg and many of those situations are already handled via just such a > > dependency. So why have the extra field? > > Because not all new policy changes are reflected by a new > version of some package? And for Developer picking up a package and > wanting to know what needs to be looked at in order to achieve policy > compliance, a mess of possible dependency relationships is a lot harder > to base that decision on than a simple standards version. OK, so if it's mainly for the benefit of the (next) maintainer, why not leave the field in debian/ but not put it into the Sources.gz file and not make an issue of it if it is out of date? It could be a comment in debian/rules. It's beginning to sound that it is neither more nor less important than the year of the copyright stamp in debian/copyright or whether a package uses CVS, SVN or git. i.e. it is a feature of the packaging and not much else. If Standards-Version is only useful for developers picking up a new package, why does that data ever have to be copied into the archive files? It's better just as a part of the .diff.gz - almost as if it was a file like debian/compat. > > Also, for Standards-Version: to be useful again, wouldn't it be > > appropriate for lintian to have support for testing the package against > > the *declared* standards version? I doubt that this would be > > particularly welcome or easy to implement, hence I agree that the field > > itself is becoming irrelevant. Yes, we can test with the version of > > That would be wrong. A Standards version has nothing to do with > deciding whether or not a package is buggy WRT policy. If it does not > match current policy, the package is buggy, period. Even if the > mainteiner has cleverly set the standards version to 0.0.0. So all packages are only tested against Policy as it is at the moment that the test is considered. Fine, so again, what is the point of having Standards-Version: in the Sources.gz file? What is the point of complaining that it is out of date when the only version of Policy that matters is the latest one anyway? > The standards version is not a means of getting out of meeting > policy. Then what is the point of the field at all? > From a Project point of view, it is useful to see if a package > in the archive meets current policy, not whether it met policy when the > standards version was last touched (and encourage people to not change > the standards version or follow policy). So assuming there is a > relation between bugginess and standards version is wrong; the latter > is only useful for people trying to update the package, so that they > know what to look for. In which case, I don't see why it needs to be preserved into the archive meta-data - it can just be left in the .diff.gz somewhere as a comment or left in the .changes file for the PTS to pick up on. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpJobnejXkOj.pgp
Description: PGP signature