On Wed, 12 Aug 2009 11:59:09 +0200 Josselin Mouette <j...@debian.org> wrote:
> However I think this approach doesn’t fit the current way we deal with > policy changes. The de facto way of dealing with policy breakages > currently is to directly report serious bugs against packages not > conforming, regardless of the Standards-Version they declare. We will > even often NMU them without changing the Standards-Version, while having > actually fixed them to conform to newer versions. 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? 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 lintian in lenny or etch but that's not really using the Standards-Version field, it's using the release process instead. Currently, lintian is taking a different approach that if the debian/changelog has not been touched since Policy was updated, it doesn't complain about tests that are new (and conversely complains if the pointless Standards-Version field is out of sync with that calculation). Presumably this is because the Standards-Version field itself isn't suitable for a lintian test, so why have the field at all? As a final thought, it would be nice to drop 10,000+ lines from the Sources.gz file too - Sources.gz doesn't need to be the same size as Packages.gz. $ grep -c Standards-Version /var/lib/apt/lists/ftp.fr.debian.org_debian_dists_unstable_main_source_Sources 13695 Interestingly, using a 'sort -u|grep -c Standards-Version' pipe gives *60* unique Standards-Versions in the current Sources for unstable. 3.0.0, 3.0.1, 3.0.1.1, 3.1.0, 3.1.0.0, 3.1.1, 3.1.1.0, 3.1.1.1, 3.2.0, 3.2.0.0, 3.2.1, 3.2.1.0, 3.5.0, 3.5.1, 3.5.10, 3.5.1.0, 3.5.10.0, 3.5.2, 3.5.2.0, 3.5.3, 3.5.4, 3.5.5, 3.5.5.0, 3.5.6, 3.5.6.0, 3.5.6.1, 3.5.7, 3.5.7.1, 3.5.8, 3.5.8.0, 3.5.9, 3.5.9.0, 3.6.0, 3.6.0.1, 3.6.1, 3.6.10, 3.6.1.0, 3.6.1.1, 3.6.2, 3.6.2.0, 3.6.2.1, 3.6.2.2, 3.6.3, 3.7.0, 3.7.1.2, 3.7.2, 3.7.20, 3.7.2.0, 3.7.2.1, 3.7.2.2, 3.7.3, 3.7.3.0, 3.8.0, 3.8.0.0, 3.8.0.1, 3.8.1, 3.8.1.0, 3.8.2, 3.8.2.0 > Currently I don’t think this header reflects anything useful in a vast > majority of our packages. I’m spending more time updating the header > than actually updating old packages to conform to policy changes. +1 It could be made optional - only set if there is a reason to set it. (Quite what those reasons would be, I have no idea but someone will probably come up with one or two.) -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpDJudKo7Onu.pgp
Description: PGP signature
