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----- --=-=-=--