[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: wine-unstable in Debian

Jonas Smedegaard <dr@jones.dk> writes:

> On 12-04-18 at 07:17pm, Simon McVittie wrote:
>> 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.
> That's hijacking in disguise. Don't do it!

I only sporadically read this thread. But isn't one of the problems with
wine that different things run with different wine versions?

Under that assumption I would think having wine-x.y packages would be a
good thing and that they should be coinstallable. They can share an
alternative for wine.

> Use the tech-committee if you run out of normal procedures. That's its 
> purpose.
>  - Jonas

As a side note: One problem with wine is that it needs 32bit libraries
on amd64 and the state of ia32-libs. Ia32-libs does have some bugs open
concerning wine, specifically it doesn't allow building wine from source
(again) and some version skews between libraries.

Since we now have multiarch this isn't going to get fixed in ia32-libs
and the wine package should no longer build on amd64 but instead
wine:i386 should be used. If anyone wants to help wine, despite the wine
package itself being blocked, then they could check the required
libraries for wine and ping the maintainers or NMU the multiarch patches
for them.


Reply to: