Bug#1142295: debian-policy: Policy major digit should match the Debian release version

Simon Josefsson <[email protected]> Mon, 20 Jul 2026 21:08:42 +0200
Newsgroups gmane.linux.debian.devel.policy
Message-ID <87qzkxh41x.fsf__29449.2172588193$1784574574$gmane$org@josefsson.org>
--=-=-=
Content-Type: text/plain

Russ Allbery <[email protected]> writes:

> Simon Josefsson <[email protected]> writes:
>
>> Indeed -- we made Rules-Requires-Root and Priority:optional irrelevant
>> recently, couldn't we also make Standards-Version an optional field?
>
>> In many packages, having that field just results in needless churn of
>> debian/ files.
>
> This comes up regularly, and maybe it's not worth having the field just
> for this reason given how much it apparently annoys people, but I've never
> seen anyone provide a good solution for the primary use case I have for
> Standards-Version: When I pick up a random package to update, I want to
> know how far back in time I have to go in looking at the Debian Policy
> upgrading checklist to see what I may need to update.

Yeah, for people initimiately familiar with that checklist I suppose
that is a good use-case for this.  The information could be in a git
commit message though?

Personally, I've never found the upgrade checklist relevant for
per-package upgrades.  I find the checklist useful to understand what
changed between policy releases, but more as a curiosity to understand
general preferences over time.

This is because 1) the upgrade checklist often lacks concrete actionable
recommendations, or 2) for those things which ARE concrete and
actionable, lintian and the Salsa CI/CD pipeline are a more
cost-effective way for me to discover what I need to do.

Granted, I do run the risk of missing something really important that
the checklist say I should do.  I find the occasional bug report about
that a more cost effective way to go about incremental over-time changes
than having uploaders re-read the checklist for every package upload.

Alas, this ought to be a separate bug report for discussion to be
useful, and I'm not sure I feel strongly about this.  I may also be
lacking context about the history and relevance of this field.

/Simon

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQNoBAEWCgMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmpecjoUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f
V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z
ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh
BLHSvRN1vst4TPT4xNc89jjFPAa+BQJp4fWRBQkOa+rdAAoJENc89jjFPAa+hWIA
/1lQvrJeGlQq50lP6tm99D1zDy7J1tQ3ha4x0Jx7rkFTAP9hpUKuTvm6m1fXyiZV
YZlu2+Id/Dq3CIAZvNF+XEr2BLgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx
I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0
+MTXPPY4xTwGvgUCaeCW1wUJDmqLVgCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R
cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE
8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J
ENc89jjFPAa+s7AA+gIIHpBApDpcDj1sKhzDngmpvwQf0VkHme6s+EG7qSgpAQDe
/XMrU0c0Pa3ji85cMqZhvzJOFI/soe662lzL0QY3Bbg4BFySz2oSCisGAQQBl1UB
BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA
JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJp4JbXBQkOaottAAoJENc89jjF
PAa+RNUA/2faQO/nFT06E+MlhlQdo/0chlQXC5TZMPTVvVBFwoLOAP9xLJK0ow5E
jTzYJB4K810AL/Iv6PEOAEgA4cPTHVlbCQAKCRBRcisI/kdFogIUAP9wnCAeS6KS
qPBlvYGyFIUK0fYJ/yze69VuUykb5quM+gEApUulFbbDT5XJAguE0rmfNa71oiD/
5W62Np31b/XGZgY=
=BfZQ
-----END PGP SIGNATURE-----
--=-=-=--