The great Debian/Ubuntu Wine packaging fork
There is a split between the Debian and Ubuntu Wine packages. It is not necessary and we (Debian) should reuse the Ubuntu packages to get the latest and greatest wine into Debian.
This article was originally written as a bug report to the wine package in Debian.
What is the split?
Right now, the Wine packages in Debian are "split": the source package produces multiple binary packages, 19 to be exact. The split packages isolates support for various hardware (camera, sound, printer, ...).
It is also a "split" with Ubuntu, which have forked about 5 years ago because of the source package split, amongst other reasons. I'll call this second split the "fork" for clarity's sake.
(The other major difference with the Ubuntu package is that by default Debian's "wine" binary is actually "winelauncher", a wrapper script that isn't recommended by upstream.)
What should we do about it?
I think we should reconsider that approach, especially considering the hard time we are having catching up even with 1.2, released over a year ago. Squeeze features 1.0 (released in 2008), even though it was released in february 2011, over 6 months after the release of Wine 1.2.
Ubuntu have mature and solid packages for Wine, and have had them for a long time. Gamers love Ubuntu for that reason.1
I believe we should just reupload the Ubuntu packages back into Debian, and talk with the Ubuntu maintainers to establish a collaboration - or just upload the packages back here ourselves, if that proves to be impossible.
I would be willing to sponsor such uploads, if necessary, but I would rather see the collaboration with Upstream (and Downstream!) re-established.
a friend, who went back to Ubuntu after we tried running 1.2 on Debian squeeze.
A bit of history: the argument for the split
Now, there is a reason for the split. It all started in 2002, when, following a feature request, print and sound components were split off the core package. The justification was added to the README.Debian in 2004, following a complaint from upstream.
So the package was split into multiple components in Debian, and that policy continued along the life of the package. The Ubuntu package took a different approach of shipping Wine all in one package. The single-package the approach is also prefered by upstream.
The rationale for the split is, according to README.Debian, that "Wine has a lot of dependencies and functionality that not all users need and want to spend disk space on".
Again according to the README, the other argument for splitting is that it provides "predictibility": "you can trust that installing libwine-print will, indeed, allow you to print".
The readme however admits that that "almost all the packages could be merged back into a big package without hard dependencies on all kinds of things."
Arguments against the split (and the fork)
Upstream believes the split causes unreliable behavior, as core components are not shipped together. They do not object to sound drivers being split however, but they would prefer having a standard way of packaging across the distros.
I would also make the argument than maintaining multiple split packages is more complex and therefore harder than maintaining a monolithic package. My guess is it's one of the things that keeps the 1.2 packages away from unstable.
I would finally make the point that, while forks can be useful and are not necessarily evil (and sometimes a necessary evil), I fail to see how this would be the case of a necessity: the "fork" (ie. Ubuntu) has more recent packages and more frequent releases than us, and I feel it would be appropriate to merge back again.
In closing
Sorry for the long post (which I should probably turn have turned into a blog), but I figured some context was important to make an enlightened decision on the future of the Wine packages in Debian.
- This is a personnal opinion here, but based on an experiment with↩