WineHQ Bug 26271

Dmitry Timoshkov dmitry at
Thu Mar 3 02:36:50 CST 2011

[Please do not exclude wine-devel when repying]

Andreas Bierfert <andreas.bierfert at> wrote:

> > That's precisely my point. How many users are prepared to compile Wine
> > from source when they report a bug with such a Wine build, and
> > somebody
> > asks them to either use a package without custom patches or compile
> > Wine
> > om their own instead? 
> I am not a normal user but the packager. Hence I at least hope to have a
> better understanding of what bugs should go upstream and what bugs are
> related to some packaging issues or custom patches. In this way I have
> no problem to rebuild or try fixes or whatever seems necessary to get
> the bug fixed.

The question was not about the packager, but about the normal users who
has a problem and wants to report a bug. What is a difference between
users using your package and crossover/ies4linux/playonlinux/etc. or
whatever packager who includes say unofficial DIB engine patches?

> >  It's very doubtful in the first
> > place that the term "official" should be used for such packages. Are
> > you going
> > to encourage packagers to include whatever patches they deem to be "an
> > important
> > feature" for the users, and still claim that provide an official Wine
> > binary
> > package?
> That raises more interesting questions: How would you describe an
> official build? What do you do if some libraries are not available and
> hence cannot build a full featured wine? But is this really the
> important question?

There is a Wine wiki page for packagers, and the bugs reporting instructions
I pointed out already. Both of them imply using "not modified in any way
Wine source".

> Of course you may ask the question: Why does the fedora maintainer
> include pulseaudio patches in the fedora wine package. And I am glad to
> give you an answer: The default fedora spin has been using pulseaudio
> for quite some time. It is an important feature of fedora. As I like to
> provide users with an out-of-the-box experience wherever possible, it is
> my duty to see and investigate where this can be provided for users.

In the first place you should ask yourself, what makes you feel that those
pulseaudio patches are really necessary? What doesn't work? Have you reported
bugs? Where? Have you tested without pulseaudio in the system and can claim
that it's the problems implied by Wine and not pulseaudio bugs?

> I never understood why wine upstream was so reluctant about including
> the pulseaudio patches. They do work well, there are people who maintain
> the patches and there is a big userbase for pulseaudio these days.

See the relevant bug report about pulseaudio support in Wine, it's been
explain many times already.



More information about the wine-devel mailing list