handling t64 backports in ppas

[Jay Berkenbilt]

On Fri, Jun 7, 2024, at 4:38 PM, Jay Berkenbilt wrote:
> 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.

A straight backport to jammy doesn't actually work because of the
versioned dependency on dpkg-dev, but I know what to do now and will
stop spamming the list. Thanks again.

--Jay