[pkg-wine-party] Bug#649238: do we really want to have a split and forked package?
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.
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
Ubuntu have mature and solid packages for Wine, and have had them for
a long time. Gamers love Ubuntu for that reason.
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!)
: This is a personnal opinion here, but based on an experiment with
a friend, who went back to Ubuntu after we tried running 1.2 on Debian
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
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.
Sorry for the long post (which I should turn into a blog), but I
figured some context was important to make an enlightened decision on
the future of the Wine packages in Debian.
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_CA.utf8, LC_CTYPE=fr_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to fr_CA.UTF-8)
Shell: /bin/sh linked to /bin/dash