wine on amd64
I would like to request permission for amd64 support to be backported from
wine 0.9.29-1 to the version currently in testing, 0.9.25-1.
While discussing this with Steve on IRC, after getting his disapproval, we
agreed to continue the discussion via mail since I wanted to explain an
ellaborate argument and prefer it archived as to avoid repeating it.
My understanding is that for each proposal you weight the necessity of the
proposed change against the chances it has to produce breakage, and the
magnitude of such. I'll try to explain why I think all three factors should
be considered in favour of wine on amd64.
I suspect that the time you spend reading this is another factor, so I'll
try to be brief :-)
Necessity of wine on amd64
The thing about amd64 support in wine, that makes it IMHO so much important,
is that there's a timeline for this feature. It's been predicted  that
the 64-bit migration will be finished in the desktop by late 2008. This
means etch is the release that will have to go through it.
Because of Microsoft serious problems producing a 64-bit port of their OS,
we have a great opportunity for expansion in the desktop area, which is
basicaly composed of users with strong dependance on win32 support (games).
If our amd64 distribution ships without wine, they'll either go for other
distributions (with a shorter release cycle, they'll all end up providing
it, or at least Ubuntu will), or be trapped with Microsoft untill the Evil
Empire[tm] has figured out how to get 64-bit drivers and 3rd party apps.
Of course, this isn't very relevant to our existing userbase; those who
want it can get wine from backports.org whatsoever. But I think it seriously
undermines our ability to expand in this area.
 based on extrapolation from Moore's law against 4 GiB barrier, see:
Chances to produce breakage
Minimal. I admit my patch is really dirty (during i386 build, puts everything
in debian/amd64.tar.lzma.uu; during amd64 build, just untars instead of
building), but it also has very small chance of breaking something. Since
my patch doesn't touch a single line of code, binaries are exactly the same,
compiled in the same environment.
Magnitude of hypothetical breakage (in case there was such)
AFAICS only xwine depends on it. If it breaks, its only one package.
My spam trap is firstname.lastname@example.org. Note: this address is only intended
for spam harvesters. Writing to it will get you added to my black list.