Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)
Sam Hartman <hartmans@debian.org> wrote:
Hi,
> Julien> Have you considered uploading a version of krb5 with: -
> Julien> libkrb5-3 - libkrb4-? - libkrb53 a metapackage depending
> Julien> on both of the above - libkrb5-dev depending on libkrb5-3
> Julien> alone and containing only the files needed to link with
> Julien> libkrb5-3
>
> That's undesirable because building without krb4 has some fairly
> significant impacts on non-library parts of the krb5 packages. So I
> could not actually build with krb4 support disabled. I guess I could
> do two build passes one with krb4 support and one without (picking up
> only the krb4 library from the krb4 build pass).
Hmm. Can't you just continue to build like you do today and separate
the two libraries? Is there a problem with doing that?
I don't know the details on the krb5 packaging, but separating out the
libraries doesn't look like a big deal. As you'll be keeping libkrb53
and add a dependency on libkrb5-3, you are covered dependency-wise, if
that's an issue.
> If I do something like this why do I want the krb4 libs to end up in a
> new package we plan to get rid of reasonably soon? Why not stick them
> directly in libkrb53? (krb4 libs in libkrb53 vs libkrb4-2 seems like
> aa mostly asthetic issue unless I'm missing something).
Oh yeah absolutely. I wasn't sure what was your plan on that, as you
were mentionning a libkrb53 split.
> Assuming that alternatives in the symbols file works, it seems like
> the only difference between your proposal and my original proposal is
> that it handles uninstalling libkrb53 somewhat better if one of the
> packages that replaces files in libkrb53 is installed. It also allows
Yes; libkrb5-3 will have a Replaces: libkrb53 right from the start,
and when you'll drop krb4 you can just drop libkrb53 altogether and
add the Conflicts: libkrb53 to libkrb5-3. That will take care of
eliminating libkrb53 and will also cover upgrades quite nicely.
> the new krb5 to migrate to testing ahead of waiting for everything to
> be rebuilt. If the alternatives approach works it means that both
> approaches allow other packages to migrate to testing.
As you note in your second reply, the goal is to decouple the
packaging change from the krb4 dismissal:
1 introduce libkrb5-3 (Replaces: libkrb53), with libkrb53 depending
on libkrb5-3, libkrb5-3.shlibs pointing to libkrb53, and a
versionned dependency on libkrb53 in libkrb5-dev
2 once it hits testing, change libkrb5-3.shlibs to point to
libkrb5-3, version the libkrb53 -> libkrb5-3 dependency and the
libkrb5-dev -> libkrb53 accordingly
3 once this latter version is built & installed everywhere in
unstable, you can schedule the binNMUs for all the rdeps
4 nobody uses libkrb53 anymore, you can drop it, drop krb4, add
Conflicts: libkrb53 to libkrb5-3 and make libkrb5-dev depend on
libkrb5-3
If you don't do (1), you risk being tied into other transitions by
your rdeps as they'll be picking up dependencies on libkrb5-3 as they
get uploaded in unstable as part of their own transitions or
development cycles.
Then (2) is the real thing, and once it's available everywhere in
unstable, you're good to go for the rebuilds of your rdeps.
In (2), you can also change libkrb5-dev to depend on libkrb5-3 instead
of libkrb53. By doing so, you'll be breaking the two problematic krb4
users, so you may want to wait a bit for that, eventually.
Until (4) happens, the problematic packages still using krb4 can still
be built and migrate to testing. That buys some more time for their
maintainers and avoid locking them out of testing, potentially
blocking other transitions.
Apart from scheduling the binNMUs, the release team shouldn't have to
care about your transition too much.
libkrb53 must be the tip of the iceberg, anything that happens below
the surface must not break other packages until (4).
(hope I haven't missed anything in the above, I've been careful in
considering every case I could think of)
> If there is some problem with the alternatives approach, then your
> approach is a clear winner.
I'm not sure the alternatives approach behaves nicely on upgrade :|
> what you suggest. I assume that with this approach I don't need to
> block on anyone for the first upload (the one with libkrb53 still
> present) and can do so at my convenience.
Yes, as long as libkrb53 remains stable and builds in unstable still
produce dependencies on libkrb53, you're not affecting anyone.
> I would appreciate your input on whether there is a good reason to
> stick libkrb4 in a new package vs sticking it in libkrb53. I'd also
As you noted, krb4 is going away, so introducing a new package is not
worth it at this point. I was mentionning a libkrb4-? package because
you wrote in your mail that you were planning to split out the
libraries in individual packages.
> appreciate your answer to whether the alternatives approach would work
> to help sanity check my understanding in this space.
Alternatives are supported in the shlibs, but I'd worry about the
upgrade path. In particular, you'd also need to version the
dependencies, and I can't remember whether that's supported in the
alternatives. Otherwise a newer libkrb53 without libkrb5 could
satisfy the dependency.
JB.
--
Julien BLACHE <jblache@debian.org> | Debian, because code matters more
Debian & GNU/Linux Developer | <http://www.debian.org>
Public key available on <http://www.jblache.org> - KeyID: F5D6 5169
GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
Reply to: