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

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.



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:

    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.


(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

    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.


Reply to: