Re: wine-unstable in Debian

[Simon McVittie <smcv@debian.org>]

On 15/04/12 15:04, Ben Hutchings wrote:
> On Sun, 2012-04-15 at 19:32 +0600, Andrey Rahmatullin wrote:
>> On Sun, Apr 15, 2012 at 01:18:28PM +0200, Petr Baudis wrote:
>>> I am rather dazzled that while there is working source package 
>>> of wine-1.5 ready, other people are working on gradually
>>> packaging wine-1.1.x releases;

Wine 1.5 doesn't seem an ideal target for a stable Debian release
(Wine follows an odd=development, even=stable branch structure, like
GNOME and Perl) but packaging 1.2 or 1.4 seems worthwhile.

>>> Also, it seems the current direction of that discussion is
>>> still to make the package "perfect" first and upload it then
>>> rather than vice versa,

It does seem like a "perfect is the enemy of the good" situation.
Ability to backport to squeeze without significant changes would be a
good thing, but not if trying to achieve it means wheezy ships with
essentially the same Wine version as squeeze; seamless support for
Win64 binaries would be a good thing, but not if trying to achieve it
means wheezy ships with a pre-2010 version of Wine that doesn't
support Win64 at all.

> If WINE 1.0 or 1.1 works better for some applications, perhaps it
> should be kept around as an alternate version.  But please let's
> have a recent upstream stable release as default (i.e. what
> 'apt-get install wine' will install).

I hesitate to suggest this if there's a possibility that the main wine
package can come up to date before we freeze, but one way to have Wine
1.4 (and/or 1.2) in the distribution without NMUs/hijacks would be a
parallel wine-1.4 source package and set of binary packages.

(I'm deliberately saying wine-1.4, not wine-unstable or wine-latest or
anything like that, because if anyone is going to use an approach
resembling "FooOffice doesn't work in 1.4, let's try 1.2", having the
actual version numbers around seems an easier way to deal with that
than an -unstable suffix pointing at a varying version; all it costs
is a trip through the NEW queue per upstream stable branch.)

    S