me to subscribe if needed).
I am also known as qjb@debian.org, upstream author and debian
maintainer of qpdf. qpdf was affected by the 64-bit time_t transition.
I maintain a ppa (ppa:qpdf/qpdf) where I backport the latest debian
version of qpdf to all supported Ubuntu versions. I believe I know how
to handle 64-bit time_t, but I want to check myself before uploading
any backports.
Today, I am releasing qpdf 11.9.1. The version in noble is
11.9.0-1.1build1, which is based on the 64-bit time_t NMU from debian.
The shared library package is libqpdf29t64 on noble and libqpdf29 on
earlier versions. 11.9.0-2 on debian incorporates the 64-bit time_t
NMU and is identical to 11.9.0-1.1 except the version number.
* For noble and newer, I can just use `backportpackage` from
ubuntu-dev-tools as I have in the past. Since noble has 64-bit
time_t, there should be no issue with this.
* For jammy and focal, I will need to build a release-specific version
of the package without the t64 changes. I already build a special
version with focal that excludes the doc package (because sphinx is
too old to build my docs on focal), so I have a working path to do
this. The versions in the ppa for focal, jammy, and mantic (if I
bother) will have libqpdf29 in them without any
provided/breaks/replaces, and so those will upgrade smoothly to the
version in the noble ppa.
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.
1. Call the new version libqpdf30t64 with the same
provides/breaks/replaces as in the t64 version of the library, and
backport the older version as libqpdf30, perpetuating the t64
stuff in the debian package. I'd have to wait until the the oldest
version of Ubuntu I routinely backport to goes out of support, and
then I could drop t64 after the next ABI change. That may be years
from now.
2. Try to do something goofy with having the backported version be
libqpdf30t32 or something, but that would be a one-off, and I
would have to do keep the provides/breaks/replaces stuff around if
I want to be able to just use backportpackage in the future. But
surely this is going to happen -- people will start making PPAs to
backport things from debian that were natively uploaded for the
first time after 64-bit time_t, and the backporters will have to
deal with this issue, right? And some of them won't think about
it. So is there a plan for this? I haven't been able to find
anything.
3. Something else I'm not thinking about? I can't remember if there's
a way I can put something in the old package that hints about its
replacement. In other words, if I could make libqpdf30 clean (no
provides/replaces/breaks) and put something in the backported
libqpdf30t32 that would achieve the same result, allowing it to be
replaced by libqpdf30 after an upgrade.
The other option would be to just not backport qpdf 12 to anything
older than noble. If this is too complicated, I may just go that way.
People can always build from source if they want it badly enough.
If this has already been worked out, feel free to just point me to
where to read. I've searched but haven't found anything. Thanks!
--Jay Berkenbilt <ejb@ql.org> a.k.a <qjb@debian.org>
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
