On 08.09.2016 21:54, Ralf Treinen wrote:
> On Thu, Sep 08, 2016 at 05:28:18PM +0200, Markus Koschany wrote:
>> 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
>
> That is certainly not true for orphaned packages with minimal maintenance
> by the QA team. At least when I do a QA upload I usually don't bump the
> Standards-Version field, simply because I don't know the package that
> well.
Right, that's also true for NMUs and this is actually one of my point of
criticisms. Now the Standards-Versions field doesn't tell you anything
about the fact whether the package is policy compliant or not. An
outdated field might just indicate that you didn't check the package or
that you forgot to update the field but it could also be fully compliant
with current Policy. Nevertheless the most recent Policy is the
benchmark when you update a package. For instance you can't claim that
newer additions to the Policy do not apply to your package despite the
fact that you haven't bumped the Standards-Version. This is what I was
referring to with "implicit expectations" of people.
Lintian is a far better tool to verify Policy compliance in my opinion
because it can be run independently from the build process and does not
require an extra debian/control field to be present. Apart from being a
reminder or bookmark, the field doesn't really tell me anything about
the current shape of your package.
Attachment:
signature.asc
Description: OpenPGP digital signature