Re: wine-unstable in Debian
Michael Gilbert <firstname.lastname@example.org> writes:
> On Wed, Apr 25, 2012 at 5:27 AM, Goswin von Brederlow <email@example.com> wrote:
>> Jonas Smedegaard <firstname.lastname@example.org> 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
>>> Â - 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:
> 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,
The plan for wheezy is that ia32-libs goes away. At least that it will
be just a transitional package that depends on the :i386 packages.
And yes, that is not yet ready so any people pitching in and getting a
library package multiarchified will help. The patches are in the BTS,
they just need to be applied.