On Mon, Jan 01, 2018 at 07:43:06PM +0100, Vincent Bernat wrote:
> ❦ 1 janvier 2018 17:47 +0100, Jonas Smedegaard <jonas@jones.dk> :
>
> >> I have very little time for Debian. Each time I update a package, I have
> >> to bump Standards-Version and fix new Lintian warnings. I would
> >> appreciate if we would assess the time developers will take to update
> >> packages because of a change.
> >
> > Only if you additionally have time to read the updated Debian Policy and
> > ensure that the package complies with that newer version, should you
> > bump Standards-Version.
> >
> > (possibly that's what you meant)
>
> I read d-d-a@ where the policy changes are announced. Most of the time, I
> feel unconcerned as I don't remember anything particular.
If a policy change doesn't affect your package (which is most of the time),
there is no hurry to upload a new version. Just bumping the standards version
isn't urgent. In fact, I don't believe it's worth an upload at all.
> > Purpose of the Standards-Version field is *not* to keep you busy
> > silencing corresponding lintian warning, but to state which version of
> > Debian Policy the package is verified to comply with.
>
> And why is it useful to know something like that?
A package may not have been updated for a while, because changes in policy
didn't affect it, but perhaps also because the maintainer was too busy. Once
you find out that there is a reason for an update, you should check if it
follows the new version of policy. You don't want to recheck all of policy, so
instead you would use the upgrading-checklist from the debian-policy package.
In order to use that, you need to read all changes between the version that it
complied with and the current version. For that, you need to know what version
it complied with. This is recorded in the Standards-Version field.
> If we don't comply with the latest policy, this is considered a serious bug.
Yes. But a package complying with the previous policy, but not the current one
is unlikely, because policy changes are normally written down once most
packages in the archive have been following the rule. Such changes are placed
in policy as a SHOULD initially, which is upgraded to a MUST (much) later.
There is usually a mass bug filing which informs you of the change and gives
you enough time to fix the issue. And if you're lucky, an NMU is already
prepared to fix the issue for you.
In other words, the problem you describe ("my package followed policy, but with
the new version it suddenly doesn't anymore") is extremely rare. Violating a
SHOULD in Policy is not a serious bug.
> We would spare a lot of developer time by not using this field anymore.
I am surprised by this statement; it makes me think you do not mean what I
understand from your email. So I'll explain what the result of removing the
field would be, please let me know if I misunderstand you:
If you remove the field, every package must always conform to the newest
version, which means that whenever a change that affects a package happens, a
new upload must be made immediately. This is exactly what you don't want, and
the Standards-Version field is what you need to prevent it.
What am I missing?
Thanks,
Bas
Attachment:
signature.asc
Description: PGP signature