[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: What’s the use for Standards-Version?



On Wed, 12 Aug 2009 11:59:09 +0200
Josselin Mouette <joss@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/

Attachment: pgpcFvpEuCXVA.pgp
Description: PGP signature


Reply to: