Re: renaming a library package (advice and sanity check)
Santiago Vila <email@example.com> writes:
> On Fri, 14 Jan 2005, Jay Berkenbilt wrote:
>> I've read Section 5.9.3 of the developer's reference and understand it
>> clearly. Is that still the best way to go?
> Not always, unfortunately. Very often, the upgrade will be smoother if
> you use empty dummy packages wisely. It's a pity that developer's
> reference does not mention dummy packages.
> For example, you can create a dummy (empty) libvips7.10-doc which
> depends on libvips-doc and has section: oldlibs. Then libvips-doc does
> not need to conflict with every version of libvips7.10-doc, only with
> the non-dummy versions.
I was planning on doing this. My goal is explicitly that this should
be as invisible as possible. The oldlibs part is important for
deborphan I suppose. I had not realized this before rereading that
part of the developer's reference.
> This way, "apt-get upgrade" will install libvips-doc without requiring
> "apt-get dist-upgrade", and this will be done automatically and
> without user intervention,
> . . . more discussion of apt-get upgrade . . .
Thank you for mentioning this. I always run dist-upgrade and had
intended to use that as my test. I hadn't considered apt-get upgrade,
but of course you're right.
>> 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.
> A more conservative approach would be to rename just libvips7.10-dev,
> libvips7.10-tools and libvips7.10-doc, and wait for the next ABI
> change to get rid of libvips7.10.
True, but I think I like going with libvips10 better. That way, the
current version of libvips will be named the way I plan to name future
versions, and the less desirable name won't be hanging around as an
example that someone else might think is right.
Many thanks for your very helpful comments.
Jay Berkenbilt <firstname.lastname@example.org>