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


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

Reply to: