On 08.09.2016 14:30, Ian Jackson wrote:
> Emmanuel Bourg writes ("Re: Network access during build"):
>> That makes sense, but in this case what is the usefulness of the
>> Standards-Version field? And more precisely, why is it considered an
>> error [1] to omit it?
>
> The field is useful because it shows the most recent version of the
> policy that the package has been checked against. It is useful to
> occasionally update packages to the latest standards, and the
> Standards-Version field can be used to spot how long it has been for
> this particular package. Policy comes with handy summaries of the
> changes, for use when checking/updating a package.
I agree with Emmanuel and I also think that the Standards-Version field
should be deprecated. People expect that a package complies with the
most recent Policy and latest standards when it is updated. That's an
implicit expectation that should not require a regular and tedious
update of a debian/control field. If a package doesn't comply with
Policy, people start to file bug reports and that can't be prevented by
using an older Standards-Version. If I want to know more about the
history of the package, I'll take a look at debian/changelog. If I want
to have a first glimpse I could also follow the link to the Lintian
summary page at tracker.debian.org which quickly tells me something
about possible Policy violations or something that could be improved.
> As a matter of courtesy to those who will come after you, in the
> maintenance of a package, I think it should always be included. It's
> your declaration of what work you have (and have not!) done.
I'd rather prefer not having to update this field every time. If I want
to learn more about the work that has been done, Git commits or the
changelog will be far more informative.
> I don't have a strong opinion about whether it should be an "error"
> for lintian, but: it is really very easy to put one in when you make a
> packaqe for the first time, and inventing one later might be tiresome.
>
>> Speaking for the Java team, on each new version of the policy we have to
>> update this field in ~500 packages actively maintained, and most of the
>> time no other change is necessary. If the field could be deprecated it
>> would save some time.
>
> You could do your checks, and update the field, much more rarely, if
> you wanted. There is nothing inherently wrong with having a
> Standards-Version which refers to a previous version of policy.
But wouldn't that defeat the purpose of the Standards-Version field, if
I don't update it even if the package complies with the most recent
Policy version?
> (A very old Standards-Version is a rather different matter: it
> suggests that the package may be rotting.)
The Standards-Version field doesn't provide reliable information in my
opinion. I have seen packages with a very old version which were in good
shape and I have seen packages with the most recent one that were not
policy-compliant. It is far more likely that we spot bit rotting when
compat levels get removed in debhelper (e.g. the recent RC compat level
4 removal) or when missing build-arch and build-indep targets in
debian/rules became release critical and people started filing bug reports.
> Is that suggestion any use ?
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.
Regards,
Markus
Attachment:
signature.asc
Description: OpenPGP digital signature