On Wed, 2023-11-22 at 01:57:50 +0000, Thorsten Glaser wrote: > Guillem Jover dixit: > >the above (waiting for EOL, or the dpkg update, or compressing > >everything with gzip) are not good options, I guess I could wait a > >bit more until say dpkg 1.23.x? It's not urgent, it would just be > >nice to get rid of them. :) > > I understand the motivation, but on the other hand I’d rather like > this to be a somewhat long-term thing.
Well, I see the patch I've got queued is from 2016, so this already seems like long term. :) In any case: > I don’t know the timelines, but 1.23.x would mean post-trixie, so > anything in trixie-backports could still use it? That’s probably > reasonable (and they get rarely updated anyway). Yes, I think backports would be fine. > To avoid a needless upload of the large packages, would you > consider first making it a no-op that warns but does not fail the > package build for the first release? Then with dpkg 1.24.0 I’d > have to definitely upload all of them (otherwise they’d be rc- > buggy) but if in the meantime any update arrives¹ I could do the > switch already. That's usually the way to obsolete these things yes, for reference this is the patch I've got queued: https://git.hadrons.org/git/debian/dpkg/dpkg.git/commit/?h=pu/default-uniform-compression&id=c9cec0fcf43ab117ea746e6787ba3bbbd3ab7f72 So if that looks good, then I'll update <https://git.hadrons.org/git/debian/dpkg/dpkg.git/tree/doc/README.feature-removal-schedule> to include the schedule for this deprecation. Thanks, Guillem
