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

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



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 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.


Reply to: