Sam Hartman <hartm...@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 <jbla...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
