handling t64 backports in ppas

[Jay Berkenbilt]

On Fri, Jun 7, 2024, at 2:11 PM, Jeremy Bícha wrote:
> On Fri, Jun 7, 2024 at 2:03 PM Jay Berkenbilt <ejb at ql.org> wrote:
> > Sometime in the next few months, I plan on releasing qpdf 12, which
> > will include ABI-breaking changes. My hope would be update the debian
> > package to libqpdf30 and drop all the t64 stuff, but doing so will
> > complicate further backports. I could do any of these and am looking
> > for advice.
>
> The easiest solution for backports is to build and name your packages
> like normal but be sure to not build your package on affected
> architectures. If you are only backporting to Ubuntu, be sure your
> package does not build on armhf. That can either be set in the source
> package or in the PPA settings.

Great, thanks. Looking at my PPA settings, it seems it is only
building for arm64, amd64, and i386. When I release qpdf 12, I'll make
sure to uncheck i386. armhf isn't even checked. By controlling it in
the PPA, I'll be able to do a straight backport. Actually, if I turn
it off right now, I can do a straight backport as the t64 package name
in jammy will be harmless. I will test upgrade path of jammy -> jammy
ppa without t64 -> jammy ppa with t64 -> noble ppa before uploading.

> If you are also doing backports for Debian, there are a few other
> affected architectures.

Right, thanks. I have no intention of doing a debian backport. There's
not enough demand, and qpdf is easy to build from source (depending
only on zlib, jpeg, and openssl or gnutls, which are all ubiquitous).

Anyway, your solution of simply disabling the 32-bit architectures is
simple, and there is probably no demand for backported qpdf packages
from my PPA on 32-bit architectures. Thanks for the quick response.

--Jay