Re: ok, i screwed up
Thomas Bushnell BSG wrote:
Santiago Vila <sanvila@unex.es> writes:
I've created libofx0 and libofx1 which are the old and new versions,
and ask the ftp-masters to drop the old package entirely. I'll
request the other user of libofx to adapt accordingly.
Gar.
PLEASE DON'T INTRODUCE NEW PACKAGE NAMES GRATUITOUSLY.
Did everyone hear that? You guys at the back?
Seriously, don't do it. It's stupid. The *only* good reason to introduce
a new package name is if you've got a new package. The *only* thing it
does is delay development because the new packages have to be manually
reviewed, and cause breakages on user's machines. Both of those are
*bad*, mmm'kay?
If you're bumping a library soname, you should do precisely one of
precisely two things:
(a) Bump the revision of the library package
(eg libfoo1.deb -> libfoo2.deb, libfoo.deb -> libfoo5.deb, whatever)
Optionally bump the revision of the -dev package's Provides
(eg libfoo-dev Provides: libfoo1-dev -> libfoo-dev Provides:
libfoo2-dev)
Upload libfoo.dsc, wait for libfoo2.deb to be approved as NEW.
Make sure everyone who uses your package upgrades to the new ABI.
This means getting a list of those packages, making sure the
maintainers of those packages know what's happening. Filing serious
bugs when the old libfoo1.deb package is removed from the archive,
and possibly NMUing those packages.
_or_
(b) Create a copy of the existing package "libfoo.dsc" called
"libfoo1.dsc". Rename "libfoo-dev" to "libfoo1-dev". Move them to
Section: oldlibs.
Update "libfoo.dsc" to the new version as per (a).
Remove any packages still in libfoo.dsc from libfoo1.dsc; ie
anything that doesn't get versioned (like foo-utils), or anything
that's versioned but didn't need a version bump (like libbar3).
Upload libfoo1.dsc, libfoo.dsc.
Make sure everyone who uses your package knows there's a new ABI to
be upgraded to. File wishlist bugs to ensure they know what's going
on. File patches to those bugs. NMU them to ensure none of them
continue to depend on oldlibs libraries.
The primary reason to do (b) is if third party apps often use the old
library. The secondary reason is if there are a lot of packages
depending on your library in Debian and you want to have a little time
to do the transition.
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.
Anyway, Thomas, I've rejected your pending uploads, please start again.
I'd suggest either:
(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.
(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".
For the libflac problems we just had, we chose (a) because there weren't
any packages linked against the buggy libflac4, and getting packages
updated to libflac6 is expected to be easy.
Cheers,
aj
Reply to: