Hi!

I've been pondering obsoleting the dpkg-deb --no-uniform-compression
option to simplify the format going forward (even though dpkg-deb will
keep accepting such packages for unpack.

This package uses this option, so I was wondering whether it can be
removed now? From the changelog it looked like it was added to help
backporting, but I think that was some time ago.

Thanks,
Guillem

Hi Guillem,

I would very much like to keep this option. It allows users of
older (in some cases very old) distributions to install the
binary packages of newer versions without bpo, which stops being
available pretty soon, and avoids certain shenaningans on the
*buntu side as well.

The “very old” here is indeed somewhat relevant as a certain
“multimedia” distribution used a lot by musicians bases on
trusty out of all things, and who knows what else.

The ability to just install the .deb files makes live easier
in these cases. If you remove the option I’ll most likely switch
the package compression to gzip (which tbh shouldn’t enlarge the
files, except the HQ one as it isn’t already Vorbis-compressed,
by too much) so if you still want this, I won’t stand in the way.

bye,
//mirabilos

Hi!

Checking https://wiki.ubuntu.com/Releases it looks like that will
reach EOL during early 2024. I see Ubuntu also backported the
relevant change to dpkg in
<https://launchpad.net/ubuntu/+source/dpkg/1.17.5ubuntu5.8>, so
perhaps that's also a viable option for those users?

I've tried building at least the musescore-* packages with gzip
and for the not-small ones the differences seem substantial. So if
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. :)

Thanks,
Guillem

Guillem Jover dixit:

It’s been EOL for desktop use since 2016 or so, and last time
I looked (2021/2022) this has not deterred people from using it.

Might be. I have no idea whether they get these updates.

OK, hmm, not so good.

I understand the motivation, but on the other hand I’d rather like
this to be a somewhat long-term thing.

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).

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.

① fluidr3mono will not receive any future updates; ms-general
  has an update under development but I have not heard of an ETA

bye,
//mirabilos

Well, I see the patch I've got queued is from 2016, so this already
seems like long term. :) In any case:

Yes, I think backports would be fine.

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

Hi Guillem,
[…]

Thanks, that looks good from a quick glance.

OK, then I’ll know when I have to at latest do an upload for these
to stop using the option, and if a rebuild happens in the meantime
they’ll just lose this earlier.

bye,
//mirabilos