Re: renaming a library package (advice and sanity check)
Jay Berkenbilt <ejb@ql.org> writes:
> The recent thread on names of library packages on debian-devel made me
> decide that I made a mistake in naming one of my packages.
> Specifically, the vips7.10 source package creates four binary
> packages: libvips7.10, libvips7.10-dev, libvips7.10-tools, and
> libvips7.10-doc. There's no reason for the version number to be in
> the name of the package since there's no reason to support more than
> one version of this library at a time.
I neglected to mention the new package names: libvips10, libvips-dev,
libvips-tools, libvips-doc. "10" is the soname of the current libvips
library. After the next ABI change, we'll have libvips11,
libvips-dev, libvips-tools, libvips-doc, etc. In other words, these
packages are low profile enough that I think the only version number
in any of the package names should be the soname in the runtime
library. This should make for the smoothest library transition when
this eventually needs to happen. (The library ABI has been very
stable, and upstream deals correctly with library sonames.) Leaving
the number out of the -dev package means that dependent packages can
just be rebuilt without any changes if the binary interface changes
but the source interface stays the same.
> The vips packages have been in the archive a short time (since
> late November or so) and only have one reverse dependency: the nip2
> package which I also maintain.
>
> Renaming the packages now will create a minor nuisance: the small
> number of users of the package will have to learn a new name for the
> package, ftp-masters will have to remove these packages that they just
> approved, and the vips packages will have to go through NEW again. On
> the other hand, it's better to fix this now than later.
>
> Should I do this rename? I think I should because the cost is low
> (since there are few users) and it's better to do it right.
>
> I've read Section 5.9.3 of the developer's reference and understand it
> clearly. Is that still the best way to go? Basically I would prepare
> new packages with the correct names and with appropriate Replaces: and
> Conflicts: lines so that installing the new packages will replace the
> old packages. Once the new packages clear NEW, I would upload nip2 to
> depend upon the new packages instead of the old packages and would
> then request removal of the old packages by posting a bug against
> ftp.debian.org.
>
> Advice welcome and appreciated. Thanks.
>
> --
> Jay Berkenbilt <ejb@ql.org>
> http://www.ql.org/q/
>
>
> --
> To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: