Re: ok, i screwed up
Thomas Bushnell BSG wrote:
Anthony Towns <aj@azure.humbug.org.au> writes:
PLEASE DON'T INTRODUCE NEW PACKAGE NAMES GRATUITOUSLY.
So it seemed to me that because of my previous mistake it wasn't
gratuitous.
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
significantly.
Yes, this was necessary in this case. The source API, according to
upstream, has significantly changed in the new 0.7.0 release of
libofx.
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
fixed)
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.
Yes.
(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"
with:
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.
Cheers,
aj
Reply to: