On Wed, Aug 12, 2009 at 10:10:43AM -0500, Manoj Srivastava wrote: > On Wed, Aug 12 2009, Neil Williams wrote: > > > On Wed, 12 Aug 2009 08:22:17 -0500 > > Manoj Srivastava <sriva...@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? ould be a comment in > > debian/rules. > > I do not have a strong opinion about this, apart from the fact > that it must be present in the sources when someone is looking to > update the package, and it should be accessible before downloading all > the sources. So having it in the diff.gz and PTS would be good enough.
The only /real/ use for the standards version is using it as a starting point for upgrading to the current standards version, and that's already making the (rather naïve) assumption that it was already fully conforming with Policy to begin with. > I also do not see much of a downside in letting current practice > be -- what are the things I am missing? For most packages, it's typically the case that a new version of Policy requires no package changes, yet one needs to trawl through the changes in the upgrading checklist and then update the version number in the control file. Basically busy-work with no actual benefit; it's just pointless make-work for the maintainer. We have an automated method for checking Policy compliance: lintian. I'd far prefer that Policy transgressions were reported first and foremost by lintian rather than requiring manual (and potentially less reliable) checking by the maintainer. Rather than depending upon the maintainer's diligence, Policy conformance would then be assessed by automated checking than the presence of a number, which is of potentially unreliable provenance in the first place. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
