Re: intent to rename vips7.10 -> vips
I've done more analysis and experimentation with the vips rename, and
I'd like to stick to my original plan of uploading a new source
package that creates new binary packages followed by creating dummy
packages out of the old source package followed eventually by
requesting removal of the old packages. In a nutshell, this requires
the least disruption in the long term and creates the smoothest
upgrade path, with the only drawback being the dummy packages. Here's
my reasoning.
You stated:
> 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.
My understanding (based on discussion that went on during the tiff
transition and stuff during my NM process) is that depending upon pure
virtual packages is frowned upon, even if only one package in the
archive provides the virtual packages. It breaks if you have a
package in your local apt that also provides the package, which I
almost always do when I'm building nip2. It would also break at some
future point when I would eventually upload a new version with a
different source package. So ultimately I feel that keeping
libvips-dev as a virtual package isn't actually just as effective
after all.
If I rename the -doc and -tools packages now, we need to go through an
override editing cycle anyway. Then I have nothing to lose by
renaming the -dev package at the same time. For that matter, I have
nothing to lose by renaming the shared library package either.
Based on Santiago's information and my own experimentation, there's no
way to get apt-get dist-upgrade and, presumably, dselect to
automatically upgrade to the new packages without using dummy
packages. Dummy packages are therefore necessary to achieve a
completely smooth upgrade.
As long as we have to go through an override editing cycle anyway, I'd
like to go ahead and take care of renaming the source package. This
also means I can use the old source package to create the dummy
packages as I originally planned. That won't require override edits
at all. Then I can request removal of the dummy packages and old
source package in some time, probably right around the release of
sarge. (I'd create an RC bug and ask the release team to remove the
packages from sarge closer to the release so sarge doesn't ship with
these dummy packages and so that that there's no urgency on removing
them from sid.)
I have a plan B that would be easier though not quite as satisfying.
That would be to leave the source package name alone for now and just
change the binary package names without creating dummy packages. Once
this goes through, I can upload nip2 that depends upon the new names.
When people upgrade that, they'll at least get the new shared library
package. They'll have to deal with -dev, -doc, and -tools manually,
but this is not a huge deal, though it will break some users. Then
the source package name is still vips7.10, which is okay but
undesirable aesthetically. Ultimately, when something > 7.10 comes
out, I'd still end up requesting removal of the vips7.10 source
package, an extra step that could be avoided if I just go with my
original plan. A future upgrade of vips would be made more complex by
having to take care of that at the same time.
So unless there are any objections that I haven't addressed (or if
I've really missed something here), I'd like to proceed with my
original plan. Is that okay?
I really appreciate the responses to this. I feel like I'm making a
lot of noise over a few packages that are not that important over an
issue that isn't that major. All this input is helping me become a
better maintainer. Thanks! :-)
--
Jay Berkenbilt <ejb@ql.org>
http://www.ql.org/q/
Reply to: