❦ 1 janvier 2018 19:45 GMT, "Dr. Bas Wijnen" <wijnen@debian.org> :
>> 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?
I don't see how you can say in the first a package complying with the
previous policy will likely comply with the current one and at the same
time saying that always complying with the latest policy is too much
work.
Moreover, if a package violates a MUST of the policy, just having an outdated
Standards-Version doesn't exempt it from getting a serious bug.
--
Remark of Dr. Baldwin's concerning upstarts: We don't care to eat toadstools
that think they are truffles.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"
Attachment:
signature.asc
Description: PGP signature