Re: wine-unstable in Debian
On Wed, Apr 25, 2012 at 5:27 AM, Goswin von Brederlow <goswin-v-b@web.de> wrote:
> 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.
All of those bugs were reported by people trying to build upstream
wine from source (which may be what you meant). But otherwise, they
are all normal bugs that have already been corrected via NMUs in the
Debian package:
http://packages.debian.org/changelogs/pool/main/w/wine/wine_1.0.1-3.5/changelog.txt
So this isn't something worth worrying about.
> 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.
It does no harm to continue to build wine with -m32 on amd64, but if
ia32-libs does go away, then all of wine's i386 multiarch dependencies
will need to be in place.
Best wishes,
Mike
Reply to: