Hi. Thanks for your work on this.
Steve Langasek writes ("Bug#1061866: adns: NMU diff for 64-bit time_t
transition"):
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> adns as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).
Thanks. I have verified that adns.h, and the ABI of adns, is indeed
affected.
> To ensure that inconsistent combinations of libraries with their
> reverse-dependencies are never installed together, it is necessary to
> have a library transition, which is most easily done by renaming the
> runtime library package.
I'm surprised at
+Provides: ${t64:Provides}
+Replaces: libadns1
+Breaks: libadns1 (<< ${source:Version})
I don't know why this isn't just a soname transition. But I think
probably people more involved in this have thoughyt this through.
(Perhaps this to do with making this a no-op on 64-bit arches.)
> If you have any concerns about this patch, please reach out ASAP. Although
> this package will be uploaded to experimental immediately, there will be a
> period of several days before we begin uploads to unstable; so if information
> becomes available that your package should not be included in the transition,
> there is time for us to amend the planned uploads.
If what I have written doesn't indicate that something has been
overlooked, you should go ahead as planned. I guess I should avoid
uploading myself.
adns is not an "unusual" package, other than insofar as time_t being
part of an ABI-exposed struct makes it unusual.
HTH.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
