On Wed, Aug 12, 2009 at 11:04:31AM -0500, Manoj Srivastava wrote: > On Wed, Aug 12 2009, Roger Leigh wrote: > > > 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 <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? 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 donot think it is a naive assumption at all. The commohn case > with most package uploads is that the previous maintainer is the > current maintainer. Usually, I try to make sure that my package is > policy compliant (don't we all? we signed up for it). Then I see what > has changed in policy since then, and try to ensure that the package > still complies with policy. > find them for me and file bugs. > > Minimizing the reading I need to do (by checking what has > changed in policy since I last checked policy) is a nice, useful > optimization. I agree on this count. My view isn't that Standards-Version is necessarily pointless, just that the current approach of having to manually review every policy change isn't necessarily the most efficient use of a maintainer's time. Given that some Policy changes have the possibility of automated checking by lintian, it would be great if lintian could highlight the non-checkable upgrade checks when it reports that the Standards-Version is out of date, i.e. looking up all changes since the current package Standards-Version for me, checking automatically what can be checked, and letting me know what the others are so I can check by hand. 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.
Attachment:
signature.asc
Description: Digital signature