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.