Dummy packages and version upgrades

[Scott Ritchie]

Last I checked, APT can get a bit confused when upgrading.

An example is Wine, which used to be split into several packages:

wine, which depends on libwine
libwine
libwine-alsa (and others), which depend on libwine

Because this split was needless and tended to break things, the packages
got merged into a monolithic package:

wine, which replaces libwine and libwine-alsa

The trouble is, adding a standard "replaces, conflicts" to the new wine
package with libwine and libwine-arts would completely confuse APT - APT
wouldn't want to remove libwine in favor of the new wine, since the OLD
Wine depended on libwine.

Since APT would refuse to upgrade the package, a common hack was to
create a "dummy package"

libwine, which depends on wine and contains nothing

This way libwine could conflict and replace libwine-alsa, have a higher
version number than libwine, and prevent APT from needlessly panicking
that it was about to remove a dependency (even though that dependency
was about to be replaced by the new wine package).

Eventually, once every user no longer had a libwine-alsa type package
and instead only had a libwine package, the dummy libwine package could
be removed by adding libwine to the list of packages that wine replaces
and conflicts.


This hack is still with us.  Extra dummy packages clutter up the APT
repository and search results when looking around for a new package.  I
propose we make some kind of systematic effort to:

1) fix the bug in APT
2) phase out the use of dummy packages meant to work around this APT bug
3) hide the fact that a dummy package is being removed from the user

Part 3 may be as simple as double checking the version update script, or
it might be as difficult as creating a special tag for dummy packages;
in the latter case, we'll need to differentiate between "empty" packages
that serve a purpose (eg ubuntu-desktop) and empty workaround packages.


Thoughts?

Thanks,
Scott Ritchie