Restoring debhelper dh5 compat for the LTS?

[Steve Langasek]

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/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20220323/2fdb2bf0/attachment.sig>