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

Re: ok, i screwed up

Thomas Bushnell BSG wrote:
Anthony Towns <aj@azure.humbug.org.au> writes:
So it seemed to me that because of my previous mistake it wasn't

See the previous message for non-gratuitous reasons to change package names. That wasn't one of them.

Bumping the actual revision of the libfoo-dev package (and having
libfoo2-dev) is only useful if the source API of the library changes
Yes, this was necessary in this case.  The source API, according to
upstream, has significantly changed in the new 0.7.0 release of

The way to tell if a package "significantly" changed it's API, is if most packages don't rebuild without significant source changes. From the other messages in the thread, that seems to be not the case. I can't see any reason to bother with keeping the old version around -- users can just keep the old libofx0c102 (?) package if they've got packages that depend on it.

(a) The last upload of libofx was buggy. Oh well, bugs happen, let's
    move on.
    Upload libofx.dsc with libofx1.deb (and ideally lintian errors
    Make sure any package that linked against the buggy libofx upload is
    fixed ASAP. Make sure any packages that link with libofx get updated
    to the new ABI RSN too.
There should be no links against the buggy libofx.  So this is the step.


(b) The old libofx needs to be supported.
    Upload libofx0.dsc with libofx0c102.deb and libofx0-dev
    Do (a), with less of a rush on "RSN".
Yes, this is still necessary.

No, it's not.

First, as I mentioned in the reject messages there's never any reason to introduce a new package into oldlibs. It doesn't help users of other packages that get removed, since it won't satisfy their dependencies anyway; and if we could live without that package name before, we can live without it now.

But second, since there are so few packages that use it, it's not worth delaying the transition; just rebuild the packages that use it and be done with it.

Note that (again as I mentioned in the reject messages) you should avoid having bins and dtds and other unversioned files in libpackages. This is so that users can have both the old libofx0c102 and libofx1 installed simultaneously, without conflicts, if they need to without you having to maintain packages in oldlibs.

source package libofx, binary packages libofx1 and libofx1-dev (in libs)
source package libofx0, binary packages libofx0c102 and libofx0-dev
  (in oldlibs)

The main libofx package should provide the current library.
The -dev package name shouldn't change unnecessarily.
A compat package should be in oldlibs only if necessary.

So, the ideal is to replace "libofx builds libofx0c102, libofx-dev"

	libofx builds libofx1, libofx-dev

This is all libofx actually needs, afaics. Note that libflac has just been in exactly the same situation, and this was how it was resolved.

The simplest level of compatability (if it's going to take ages to rebuild all the packages, but they're relatively easy to rebuild, or if important non-debian/non-free apps require the old version)

	libofx builds libofx1, libofx-dev
	libofx0 builds libofx0c102

(ie, take the old version, and make it only build the lib, not the -dev package and rename the source package)

If people need to be able to build packages against the old libary as well (if it's part of the LSB spec is the only reason I can think of), you'll want:

	libofx builds libofx1, libofx-dev
	libofx0 builds libofx0c102, libofx0-dev

(ie, take the old version, rename its -dev package, and the source package)

Note that in all the cases, we can just drop libofx0.dsc and forget libofx0 ever existed.

If there's a major API change, and packages are continuing to be developed against the old library because, say, the new version has dropped some features as part of a major rewrite that haven't yet been readded, you'll want:

	libofx1 build libofx1, libofx1-dev
	libofx builds libofx0c102, libofx-dev

Note that in this case, libofx stays the same, and it's a matter of uploading a new libofx1 source package, that builds .debs under new names. Why? Because you've effectively got a completely new library, old binaries won't work with it, old sources won't build against it, and it doesn't even obsolete the old one. This way of doing things means you don't break any old dependencies, and have complete control over what dependencies (normal or Build-) the new packages satisfy. It also means you only have to wait for one package to be processed through NEW.

You don't normally need this case at all. For values of "normally" approaching "ever".

There's no particular need to fix libofx0c102 in unstable before completely replacing it with libofx1 -- things break in unstable, it happens. The fix for unstable users is just rebuilding everything to work with libofx1; if they really care they can get the old working libofx0c102 from testing or their apt cache.

But if you really feel it's necessary, upload the source to "libofx 0.6.6-2.1" with the version number bumped to something greater than 0.7.0-1 (0.7.0really0.6.6-3 maybe). Once that's been accepted, upload the fixed libofx 0.7.0 package with a still higher version number. You're really better off just getting libofx 0.7.0 uploaded correctly, and everything that depends on the old lib fixed and/or NMUed though.


Reply to: