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 <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
