Bug#479659: RFH: wine -- Windows API implementation
Stephan Hermann skrev:
Fun part, do we know how many people are using the official wine
packages from debian, and how many debian user are using the inofficial
ones provided from winehq?
No, but such a figure would only be meaningful if all else was equal,
which is not the case. Debian has a very long release cycle, so the Wine
version in etch is ancient (0.9.25). So when etch users get desperate
for something newer, where do you think most of them will go? On WineHQ,
they'll only find the Ubuntu-like packages, nothing based on the
official Debian packaging (and they don't even know it). So for these
users, it's a Hobson's choice: Ubuntu-like packages or nothing.
I'm sure even a lot of testing users were driven there during the long
periods when I just wasn't updating the official packages. And ever
since, I've had bug reports from people using the winehq packages,
because they didn't know there was a difference, not because they liked
the winehq ones better. Most users really only care getting the newest
version, and Debian hasn't had an edge in that department (though
hopefully a comaintainer would do something about that).
So, "fun" perhaps, but nothing else.
AFAIK (this happens at least on Ubuntu) most people are using the new
crack packages from winehq...since Scotts not in the Ubuntu MOTU team,
we have at least a sync between winehq and ubuntu in general. And it
seems, this pleases the user much more...:)
New versions are always pleasing.
I'm pretty sure they would have seen this RFH anyways since I did Cc
wine-devel (which they presumably read) when filing it, but I only
expected them to answer if they're fine not doing things the Ubuntu
way
- which pretty much means I don't *really* expect them to answer, I
guess.
You guessed wrong :) At least it would be good to follow the "one way
to go" policy for both distros :) for the users sake...not the
developers ;)
I'm not sure there's a real need for that. Debian and Ubuntu has
different target audiences, different development models, and different
policies. Debian is an "universal" OS, designed to be deployed on
anything from a PDA to a supercomputing cluster. This means a bunch of
package customization is appropriate, and there are lots of guidelines
and rules to follow when doing packages, which may easily involve not
doing things the way upstream does. Ubuntu is really more of an end-user
desktop distro, where RPM-like solutions and development models are fine
- and if it works, it gets shipped. (Ubuntu in general doesn't exactly
shine in the technical excellence department, if I understand my fellow
Debian Developers correctly.)
So the packaging for Debian and Ubuntu could perfectly reasonably be
different, if users could get both on WineHQ.
From your other mail:
IMHO, Scotts package is quite in a good shape, regarding support and
bugfixes + Win32 support on x86_64 archs...
We don't need to rely on anything else then some lib32* compiled
packages on amd64 and the stuff inside ia32-libs...
So? That's trivial. My packages are also available for amd64, and it
would be easy to compile it natively on them if Debian actually had a
decent ia32-libs that wasn't broken. This has nothing to do with
differences in Wine packaging.
In fact, it would be on amd64 that my packaging scheme really shines.
Let's say the ia32-libs split finally happened, and everything was
available as individual lib32* packages. What mess would users be in then?
You want to print on Debian? If you got libwine-print, you can print.
You want to print on Ubuntu? "WTF? I didn't know I needed to install
lib32cups *and* cupsys-bsd, my other Linux apps can print without"
You want to play sounds using JACK? If you got libwine-jack, you can
play audio. You want to use JACK on Ubuntu? "WTF? I need to install
lib32jack, sounds work everywhere else without"
You want to scan with SANE? If you got libwine-sane, you can, and so on,
and so forth. Nothing would work differently between i386 and amd64, or
be more difficult on either.
And if you install the "wine" metapackage on Debian, you can of course
get everything all at once, where everything Wine can offer would Just
Work, even on the amd64 platform after the ia32-libs split.
I'm not abandoning such user convenience for the RPM-like packaging
Ubuntu uses. I personally chose Debian as my distro to try to get away
from such broken models. To Debian, technical excellence matters (which
is where all the bureaucracy, procedures, and rigid policy documents
come from).
(That said, if someone got consensus on the debian-devel ML that your
way *is* better, I'd probably have to give in...)
Furthermore, Ubuntus wine package does compile without any hassle on
lpia archs..
And what's that supposed to mean?
Ove, when you are interested to pick up Scotts Packages (he's the
winehq debian package maintainer actually) I think we would be glad to
help in the transition.
Unfortunately probably not gonna happen anytime soon...
Oh, and sorry if I seem to be flaming a little. I just want my POV to be
clear.
Reply to: