Re: intent to rename vips7.10 -> vips
Anthony Towns <aj@azure.humbug.org.au> wrote:
> Jay Berkenbilt wrote:
>> The recent threads on sonames and package names convinced me beyond a
>> doubt that I made a mistake in the names of the vips packages.
>
> Oh dear...
>
>> [...] Right now, the vips7.10 source package creates four binary
>> packages: libvips7.10, libvips7.10-dev, libvips7.10-tools, and
>> libvips7.10-doc. My intention is to do the following:
>
>> Create new source package "vips" which will create four binary
>> packages: libvips10, libvips-dev, libvips-tools, libvips-doc. (10 is
>> the current soname.)
>
> There's no real reason to change "libvips7.10" to "libvips10" -- the
> package name doesn't have to match the soname, it just has to change
> whenever the soname does. So if you've matched "libfoo" to a soname of
> 4, you don't have to do anything beyond renaming the package when
> version 5 comes out -- and that's the point you should say "ah, I can
> call it libfoo5 now".
Well, I can just leave libvips7.10 alone then and wait for the next
soname change (or C++ transition), at which point I can do the one and
only inconsistent name change and switch to using the soname, which I
find preferable, especially for packages where the upstream maintainer
deals with sonames well. I guess I'm still trying to find the right
balance between living with a past mistake that doesn't really matter
that much vs. fixing up as many things as I can in one shot. If this
were a more visible package, I wouldn't consider as radical a change.
> Changing the -dev package name isn't a huge win -- having it
> Provides:/Conflicts: with "libvips-dev", encouraging your users to
> build-depend on the unversioned -dev, then just changing the package
> name when your soname next gets bumped is just as effective.
Luckily, I had already had these Provides:, but not the Conflicts. On
the other hand, libvips7.10-dev conflicted with libvips7.8-dev (now
gone -- thanks), so the right thing should happen. Maybe a note in
README.Debian would be in order.
> OTOH, when the soname gets bumped you generally don't want to change
> the source package name so you get to avoid waiting for bugs like
> #283145 to be dealt with, and source package names basically don't
> affect users at all.
>
> libvips-tools and libvips-doc likewise can probably lose their version
> happily, presuming people who Depend: on libvips-dev today, and end up
> getting the tools from soname 11 aren't going to be unhappy. But for
> both of those you should be able to just have "libvips-*
> Conflicts:/Provides:/Replaces: libvips7.10-*" to satisfy dependencies.
Well, since the libvips7.10-* packages provide the corresponding
libvips-* packages now, it sounds like another possibility would be to
just leave this alone for now and wait for a new soname change before
bothering to change the source package. Then when I do, I will change
it to "vips", and it will be the last time it has to change. Then I
can request removal of vips7.10. Once that's done, I don't have to
mess with removal requests anymore. vips is a mature and stable
package, so this could be a ways off.
My main concern here is that any kind of change like requires
intervention from an ftp master and a delay (not complaining!) from
the maintainer's perspective while the package is in NEW. I was
thinking that if I was going to change any package names, I may as
well get it the way I wish I had done it originally. You're in a
unique position to comment on this aspect. :-)
>> Each package Conflicts with the package it
>> replaces with a version << the future dummy transition version of the
>> existing packages and Replaces the old package as well. For example:
>
> I'm fairly sure the above should ensure you don't need any dummy
> packages, and gain all the benefits you were aiming for. Dummy
> packages are almost always evil.
Yes, I understand. Simply reversing which is the actual package name
and which is the Provides: could alleviate the need for dummy packages
since only one real package will match libvips7.10{,-dev,-tools,-doc}.
I'll still simulate this locally to make sure I completely have worked
out what will happen in the various scenarios. I have no idea what
apt-get dist-upgrade would do in this case, but it will be easy for me
to find out. I would certainly prefer an option where users are not
left with useless empty packages on their systems.
As for the whole discussion in subsequent messages about using dummy
packages or not, it's an interesting and important discussion but, at
the end of the day, it's not a huge deal for these packages. They are
very new and probably not installed by very many people. They have
also never been in a stable release.
> Santiago Vila wrote:
>> On Mon, 17 Jan 2005, Anthony Towns wrote:
>>>>Each package Conflicts with the package it
>>>>replaces with a version << the future dummy transition version of the
>>>>existing packages and Replaces the old package as well. For example:
>>>I'm fairly sure the above should ensure you don't need any dummy
>>>packages, and gain all the benefits you were aiming for.
>> The point is not about "needing" dummy packages or not.
>
> Well, yes it is -- they're not there for their own sake, they're there
> to ensure upgrades happen smoothly and automatically. If they're not
> *necessary* for that, they're not useful -- any other way of achieving
> it is better.
>
>> The point is whether dummy packages are useful, and yes, they are
>> useful indeed. Unless things have changed recently, dselect does
>> *not* select a new package to be installed, no matter how many
>> Conflicts:/Provides:/Replaces: on the old package it has.
>
> We really need to get dpkg/apt and dselect/aptitude working as
> designed. Not supporting auto-selecting packages like this, in spite
> of it having been documented for years, is just embarassing.
>
>> So yes, we *need* dummy packages for upgrades to be smooth.
I came into debian late enough to not really ever get used to using
dselect. I didn't even consider it in planning this. Hmm.
> Although given the -tools and -dev packages have already been renamed
> from libvips7.8-tools to libvips7.10-tools without bothering with
> dummy packages, there's not much point starting now.
I tend not to like using past mistakes as an excuse for future
mistakes. :-)
There are really two reasons for the lack of any kind of smooth
transition between 7.8 and 7.10. One is that vips 7.8 was only there
for a very short time when 7.10 was released, and the vips 7.8
README.Debian always mentioned that 7.10 was coming out soon. I
uploaded 7.8 shortly before the originally announced August freeze for
sarge. Had it been clear at the time (to me) that sarge would be
delayed, I would have just waited for 7.10. libvips7.8 and
libvips7.10 couldn't coexist because of files in /usr/share/vips, so
having two separate versions for that was utterly useless and
definitely an error in judgment on my part.
The second reason is that my mind had been contaminated by the xerces
packages, which I also maintain. There are multiple versions of
xerces in the archive because each new release introduces
non-backward-compatible changes, and several external packages tend to
depend upon a specific version. Although this seems to be a real
issue for xerces, it is certainly not an issue for vips, and it was
incorrect for me to follow the xerces model for vips. When I started
helping out with xerces, there were already two versions in debian.
Now there are five. Post sarge, I'm planning to take a hard look at
cleaning that situation up too. We also have this same thing with ICU
(on which xerces depends) -- the "icu" package and the "icu28" package
both exist. I may try to take over or help with the "icu" package and
bring it up to date. At least now I know better than to package
"icu32" with the new upstream version! (I wonder why icu28 was
created as a separate package, but that's another topic.)
--
Jay Berkenbilt <ejb@ql.org>
http://www.ql.org/q/
Reply to: