[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 64-bit time_t: updated archive analysis, proposed transition plan with timeline



>>>>> "Steve" == Steve Langasek <vorlon@debian.org> writes:

    Steve> - In multi-library packages, there is no reliable way to map
    Steve> from a set of headers in a dev package to specific shared
    Steve> libraries in a runtime library package that's not
    Steve> additionally computationally prohibitive; we therefore
    Steve> conservatively assume that if any headers from a source
    Steve> package show time_t ABI changes, all the runtime library
    Steve> packages from the source package are affected by the
    Steve> transition.  This seems sensible in general, but er, in the
    Steve> pathological case we have Source: zlib that now ships both
    Steve> zlib1g-dev and libminizip-dev, zlib1g-dev is confirmed to not
    Steve> be ABI breaking, libminizip-dev has failed to analyze, and we
    Steve> don't want to force a transition for zlib1g because of
    Steve> libminizip (!).  Current plan is to simply special case
    Steve> zlib1g, but there could be other problem packages we haven't
    Steve> identified.

I think krb5 may be in this category.
In particular, it looks like time_t is only exposed in the kdb.h API,
which appears to have no reverse depends outside of krb5.
I actually think that the freeIPA server may have a plugin that depends
on kdb.h, and Samba4 can be built in such a way that it depends on
kdb.h, but it looks like neither of those applies to the Debian archive.


At one level, krb5-multidev only has an rdep of 5, but I suspect the
rdep count for libkrb5-dev is somewhat larger:-)
I don't know how many packages would be removed from the transition if
we decide most of the krb5 libraries do not need to transition.

Attachment: signature.asc
Description: PGP signature


Reply to: