FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-22-2009, 10:46 PM
Russ Allbery
 
Default Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)

Just a couple of process notes.

Sam Hartman <hartmans@debian.org> writes:

> I propose to upload a version of krb5 to unstable in about a week that
> is basically identical to the krb5 in experimental. I will include some
> debconf fixes, a news file, and other minor changes. See the
> experimental branch of [2] for ongoing work towards this upload.
>
> [2] git://git.debian.org/git/pkg-k5-afs/debian-krb5.git

debian-release should sign off on the timing before we start the
transition, and it may be that they'll want you to hold off due to other
things already in motion. The goal is generally to avoid tangling
together multiple transitions, which makes it very hard to get things to
migrate into testing.

> Unfortunately, there are a lot of packages that reverse depend on
> libkrb53. All of these packages will need to be rebuilt.
> Here's where I need sanity checking.
>
> I assume that after the new krb5 has made its way into unstable and has
> built on all arches, I should send mail to all these packages asking
> them to upload a new version built against the new krb5.

You, and the maintainer, shouldn't have to do anything here. Since the
API didn't change for applications that don't use Kerberos v4, this can be
done via binNMUs triggered by the release team. Maintainers should
generally *not* do sourceful uploads since the name of the development
package has not changed. Build dependencies should similarly not need to
change.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-23-2009, 08:51 AM
Julien BLACHE
 
Default Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)

Sam Hartman <hartmans@debian.org> wrote:

Hi,

> That is, if I made the dependency in libkrb5-3.symbols look like
> libkrb5-3|libkrb53 (and similar changes for other symbols files), then
> both the packages in unstable and testing would satisfy the
> dependencies. It seems like this would significantly reduce the
> impact of the transition. Am I missing something or would this change
> be a good idea?

Have you considered uploading a version of krb5 with:
- libkrb5-3
- libkrb4-?
- libkrb53 a metapackage depending on both of the above
- libkrb5-dev depending on libkrb5-3 alone and containing only the
files needed to link with libkrb5-3

Then you can do a smooth transition that won't break anything. Wait
until that version makes it to testing and then ask for binNMUs for
anything that can be binNMUed and still depends on libkrb53.

Once you're all done, get rid of libkrb4-? and libkrb53 (add a
conflict on libkrb53 in libkrb5-3 to force the removal?).

That should ease things quite a bit, especially given the number of
rdeps...

JB.

--
Julien BLACHE - Debian & GNU/Linux Developer - <jblache@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-23-2009, 12:57 PM
Sam Hartman
 
Default Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)

>>>>> "Julien" == Julien BLACHE <jblache@debian.org> writes:

Julien> Sam Hartman <hartmans@debian.org> wrote: Hi,

>> That is, if I made the dependency in libkrb5-3.symbols look
>> like libkrb5-3|libkrb53 (and similar changes for other symbols
>> files), then both the packages in unstable and testing would
>> satisfy the dependencies. It seems like this would
>> significantly reduce the impact of the transition. Am I
>> missing something or would this change be a good idea?

3 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).


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).


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
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.

If there is some problem with the alternatives approach, then your approach is a clear winner.

I actually think allowing the new krb5 package to migrate to testing
is worth a second build pass on the krb5 package, so I'll do roughly
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.

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
appreciate your answer to whether the alternatives approach would work
to help sanity check my understanding in this space.


Thanks,

--Sam


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-23-2009, 01:06 PM
Sam Hartman
 
Default Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)

>>>>> "Sam" == Sam Hartman <hartmans@debian.org> writes:

>>>>> "Julien" == Julien BLACHE <jblache@debian.org> writes:
Julien> Sam Hartman <hartmans@debian.org> wrote: Hi,

>>> That is, if I made the dependency in libkrb5-3.symbols look
>>> like libkrb5-3|libkrb53 (and similar changes for other symbols
>>> files), then both the packages in unstable and testing would
>>> satisfy the dependencies. It seems like this would
>>> significantly reduce the impact of the transition. Am I
>>> missing something or would this change be a good idea?

Sam> 3 Julien> Have you considered uploading a version of krb5
Sam> 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

Sam> That's undesirable because building without krb4 has some
Sam> fairly significant impacts on non-library parts of the krb5
Sam> packages. So I could not actually build with krb4 support
Sam> disabled. I guess I could do two build passes one with krb4
Sam> support and one without (picking up only the krb4 library
Sam> from the krb4 build pass).


Sam> unless I'm missing something).


Sam> Assuming that alternatives in the symbols file works, it
Sam> seems like the only difference between your proposal and my
Sam> original proposal is that it handles uninstalling libkrb53
Sam> somewhat better if one of the packages that replaces files in
Sam> libkrb53 is installed. It also allows the new krb5 to migrate
Sam> to testing ahead of waiting for everything to be rebuilt. If
Sam> the alternatives approach works it means that both approaches
Sam> allow other packages to migrate to testing.

Ah, I was missing something. It allows us to decouple when we
generate a bunch of binary NMUs from when we turn off krb4. When I
upload the new package, nothing breaks in unstable, so there is no
particular need for the release team to do anything under any time
pressure.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-23-2009, 02:21 PM
Julien BLACHE
 
Default 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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-23-2009, 03:19 PM
Sam Hartman
 
Default Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)

>>>>> "Julien" == Julien BLACHE <jblache@debian.org> writes:

I really appreciate your help here!

Julien> As you note in your second reply, the goal is to decouple
Julien> the packaging change from the krb4 dismissal: 1 introduce
Julien> libkrb5-3 (Replaces: libkrb53), with libkrb53 depending on
Julien> libkrb5-3, libkrb5-3.shlibs pointing to libkrb53, and a
Julien> versionned dependency on libkrb53 in libkrb5-dev

Julien> 2 once it hits testing, change libkrb5-3.shlibs to point
Julien> to libkrb5-3, version the libkrb53 -> libkrb5-3 dependency
Julien> and the libkrb5-dev -> libkrb53 accordingly
Julien> If you don't do (1), you risk being tied into other
Julien> transitions by your rdeps as they'll be picking up
Julien> dependencies on libkrb5-3 as they get uploaded in unstable
Julien> as part of their own transitions or development cycles.

I'm sorry, but I don't see how I get stuck in unstable if I start out
with the libkrb5-3 shlibs and symbols files pointing to libkrb5-3
rather than libkrb53. As I understand it, rdeps can only hold me in
unstable if moving my package into testing would make them
uninstallable in testing.

They depend on libkrb53 with a versioned dependency today.
A version of libkrb53 that is greater than any existing versioned dependency will be in my package migrating from unstable to testing, so their versioned dependency will be satisfied.
I don't know if we do build-dep related blocking today or not, but the build-deps on libkrb5-dev will continue to work.

In addition, since libkrb53 will pull in all the krb5 libraries a
package that depends on it will actually get the libraries it needs to function.

Now, I might hold my rdeps in unstable if for some reason it takes a
while for the new krb5 to migrate into testing. However that's no
more true than if I added some symbols to one of my libraries and
upgraded my versioned dependency. Still that's a reason to leave the
shlibs and symbols files pointing at libkrb53 until I make it into
testing.

The krb4 using packages are all leaf packages, so they will not
complicate things until libkrb53 goes away.


I trimmed the reply text, but you asked why I need two build passes.
The krb5 package includes a bunch of libraries as well as daemons,
utilities etc. Building with krb4 enabled does more than build krb4
libraries, and I want to get the affects of building with krb4
disabled for daemons and utilities. Doing two build passes will be
easy given my package structure and the package does not take
particularly long to build.

--Sam


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-23-2009, 03:49 PM
Julien BLACHE
 
Default Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)

Sam Hartman <hartmans@debian.org> wrote:

> I really appreciate your help here!

Thanks!

> I'm sorry, but I don't see how I get stuck in unstable if I start out
> with the libkrb5-3 shlibs and symbols files pointing to libkrb5-3
> rather than libkrb53. As I understand it, rdeps can only hold me in
> unstable if moving my package into testing would make them
> uninstallable in testing.

Yes you are right about this.

> Now, I might hold my rdeps in unstable if for some reason it takes a
> while for the new krb5 to migrate into testing. However that's no

And that's what what I had in mind and wrote the other way around

> more true than if I added some symbols to one of my libraries and
> upgraded my versioned dependency. Still that's a reason to leave the
> shlibs and symbols files pointing at libkrb53 until I make it into
> testing.

It's not strictly necessary as you pointed out, but in the end it
makes the transition even smoother and protects against anything that
could come up in the 10 days you'll spend in unstable with the new
version.

A bit over-engineered maybe, but I like doing transitions (and not
only package transitions in Debian ) in a way that provides me with
a big switch to throw once everything is ready while still having
options for pausing or backing out if anything comes up.

> The krb4 using packages are all leaf packages, so they will not
> complicate things until libkrb53 goes away.

That's what I got from your initial mail.

> I trimmed the reply text, but you asked why I need two build passes.
> The krb5 package includes a bunch of libraries as well as daemons,
> utilities etc. Building with krb4 enabled does more than build krb4
> libraries, and I want to get the affects of building with krb4
> disabled for daemons and utilities. Doing two build passes will be

Oh, OK. That doesn't necessarily have to be done when introducing
libkrb5-3, but that's entirely your call of course.

> easy given my package structure and the package does not take
> particularly long to build.

That's a big help in this case!

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-23-2009, 04:04 PM
Sam Hartman
 
Default Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)

OK, so I think we're all set.

The plan now is to

1) Build twice, once into build and once into build-krb4. We only
pull libkrb4.so out of build-krb4. 2) Move all the libraries out of
libkrb53 and libkadm55 (sorry, in my previous mails I was simplifying
a bit) except for libkrb4.so.2.

3) Make libkrb53 depend on all the libraries it now contains and libkadm55 depend on the libraries it contains.


4) Set up symbols and shlibs files to point everyone at libkrb53 and
libkadm55 as appropriate.

--------------------

At some point after the new krb5 enters testing:

5) Point symbols files at libkrb5-3 and friends--point them at the
package that contains the library.


--------------------

When the first release of krb5 1.7 enters debian (probably beta1):


6) Drop libkrb53 (and thus the libkrb4.so.2), libkadm55 from the
package. If the old krb4 library fails to work against the new
libkrb5-3 in 1.7, add a conflicts line. Otherwise leave the
conflicts line off for now.


At some point later, add a conflicts line if we did not do so in step 6.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-23-2009, 04:17 PM
Julien BLACHE
 
Default Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)

Sam Hartman <hartmans@debian.org> wrote:

Hi,

> OK, so I think we're all set.
>
> The plan now is to

Looks good!

> 1) Build twice, once into build and once into build-krb4. We only
> pull libkrb4.so out of build-krb4. 2) Move all the libraries out of
> libkrb53 and libkadm55 (sorry, in my previous mails I was simplifying
> a bit) except for libkrb4.so.2.

I guessed that looking at the various packages

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-27-2009, 03:40 AM
Sam Hartman
 
Default Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)

>>>>> "Sam" == Sam Hartman <hartmans@debian.org> writes:

Sam> OK, so I think we're all set. The plan now is to

Sam> 1) Build twice, once into build and once into build-krb4. We
Sam> only pull libkrb4.so out of build-krb4. 2)

This works at least.


Sam> 3) Make libkrb53 depend on all the libraries it now contains
Sam> and libkadm55 depend on the libraries it contains.


Sam> 4) Set up symbols and shlibs files to point everyone at
Sam> libkrb53 and libkadm55 as appropriate.


It turns out this fails impressively. The problem is that the library
packages depend on each other. So, for example, libk5crypto3 is
needed by libkrb5-3. If I make the shlibs file for libk5crypto3 point
to libkrb53 instead of libk5crypto3, then libkrb5-3 depends on
libkrb53. But libkrb53 depends on libkrb5-3 because that is the point
of libkrb53 in the new layout.

I probably could hack something that would work: use symbols files
that point at the split library packages internally and just before
the debs are constructed run a sed script on symbols and shlibs.


However as you'll recall the only reason we didn't point the shlibs at
the new packages initially is to make things easy for unstable
packages that get rebuilt while the new krb5 is waiting to migrate to
testing.

My proposal now is to upload with urgency medium. There are no code
changes , I have high confidence that I can shake out any packaging
bugs in five days, and that provides a good compromise in my mind at
least between not blocking other people too much and having a simple
enough transition strategy that I can have high confidence I
understand it and that it will work.

If that sounds too problematic then I can investigate the option of
symbols files with alternatives (I.E. libk5crypto3|libkrb53 in the
symbols file.




and In addition, either versioned replaces
don't work as well for downgrades as unversioned replaces, or replaces
on unpacked but not configured packages don't work as well as replaces
on installed packages.

I'll use unversioned replaces if the user experience is better,
versioned replaces otherwise. (I had used unversioned replaces in
experimental, but was trying versioned in my current work).



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 07:02 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org