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

Re: Standards-Version field should be deprecated



On 08.09.2016 17:39, Russ Allbery wrote:
> Markus Koschany <apo@debian.org> writes:
> 
>> I have written a macro to update the Standards-Version field because it
>> is such a boring task. Declaring compliance with the Policy over and
>> over again by updating this field and mentioning it in the d/changelog,
>> doesn't strike me as being a useful task. There are better ways to
>> determine bit rot IMO.
> 
> If Lintian says that the Standards-Version field is out of date, I then
> open /usr/share/doc/debian-policy/upgrading-checklist.txt.gz, scroll down
> to the current value of Standards-Version, and then read backwards to the
> top, checking each item against my knowledge of the package to see if
> there's anything I need to update.  Then I update Standards-Version in the
> packaging.
> 
> If you're just automatically updating it without ever looking at how
> Policy has changed, then yes, it's not useful.  And I don't think it's
> very useful to publish.  But if you use it as a bookmark for the
> maintainer so that you know what version you last checked the package
> against and therefore what bits of the upgrading checklist you need to
> check, I think it's pretty helpful.

I didn't want to imply that we don't check the Policy before updating
the field, just that it is such a repetitive task for team-maintained
Java packages (which can all look quite similar), that you need some
kind of tool to keep your sanity. Even for non-Java packages I find that
the Standards-Version field is not useful enough to warrant its
inclusion in debian/control. There are other ways how you can remind
yourself to check your package against a new Policy release with tools
outside the source package. In my opinion it has more to do with how you
organize yourself and maintain your packages.

> I will say, though, that it's much more useful for individual packages
> than it is for large sets of team-maintained packages where you're more
> likely to change Policy-related things across all packages at once.





Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: