Re: Standards-Version field should be deprecated

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Josh Triplett writes ("Re: Standards-Version field should be deprecated"):
> Ian Jackson wrote:
> > Editing the Standards-Version field is surely a small task, compared
> > to the work of checking the policy updates against the package.
> 
> Not necessarily.  You can check Policy once for the differences
> introduced with a new version, determine quickly from the nature of the
> changes that none of them can apply to any of your team's 500 packages,
> and then have 500 packages to update.

Any approach which does away with the source-package-specific
Standards-Version field needs to keep the same inforamtion somewhere
else.

If a situation like you describe arises, then it is surely a simple
matter to update the out-of-source-package update-tracking information
to say "we have checked that S-V update X->Y does not affect us".

The actual S-V in the actual source packages does not need to be
updated right away.  The cost of not updating it is that someone else
who isn't in the team and doesn't know about the out-of-source-package
tracking info might redo some of the policy review, but that's not
normally very onerous.

The source packages' S-V fields can be updated when it's convenient.

> I do see value in documenting the version of Policy a package complies
> with.  However, I can also imagine some approaches to eliminate the
> busywork.  For instance, define a missing Standards-Version (or an
> explicit field like "Standards-Version: current") as meaning "complies
> with the latest version of Policy as of the date of the last
> debian/changelog entry".

I'm afraid I agree with Steve's criticism of this idea.

Thanks,
Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.