On Wed, Mar 23, 2022 at 06:50:26PM +0000, Robie Basak wrote: > On Wed, Mar 23, 2022 at 02:58:27PM +0000, Dimitri John Ledkov wrote: > > Please don't. There are many bugs in older compat level that may produce > > debs no longer compatible with our OS. Especially around generated > > maintainer scripts.
> > It's best to upgrade packaging to compat level 13. Sounds like a long > > overdue packaging upkeep. > I understand the principle here, but it seems very late in our cycle to > be suddenly finding ourselves with the task of doing this for the entire > archive. What changed that suddenly makes this urgent for _this_ cycle > in particular, apart from that someone noticed? Some facts: - debhelper 7, which superseded compat level 5, is 12 years old. Any package in the archive that is still using debhelper compat level 5 has SERIOUSLY unmaintained packaging. (I'm pretty sure, for instance, that lintian has had warnings about this for a while; so at minimum, a responsible maintainer looking at the output of lintian before uploading should have picked up on this issue well before now.) - Any package using compat level 5 does not, for example, get automatic support for default build flags from dpkg-buildflags. This means any binaries built with compat level 5 should be considered insecure and dangerous in their own right at this point, due to the lack of compiler security flags. - The merge of the debhelper version from Debian that included this change (which was decided upstream) happened on February 14. This was well before Feature Freeze on February 24. While in an ideal world someone making this change would have communicated proactively to the Ubuntu developers that it was coming and what impact it would have had, the lack of such communication does not, in my view, invalidate the decision to do the merge from Debian. > I don't have a strong view on the technicalities here, but socially it > seems pretty harsh to suddenly impose this on development teams who are > already busy due to what amounts to an accident of timing for general, > tech-debt type improvements rather than something that directly impacts > user experience. It'd be nice to see a compelling reason to push for > more late notice work that doesn't rely on the word "may". From my perspective, it is the responsibility of teams to factor time post-FF for the fixing of build failures into their capacity planning, and furthermore, the impact of this *particular* change on archive buildability should be rather small. I see no reason to revert the change in question. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
