ia32-libs [was: Bringing Wine into Main]

[Scott Ritchie]

Stephan Hermann wrote:
> Moins,
> 
> On Wed, 2008-12-17 at 09:35 -0800, Scott Ritchie wrote:
>> Martin Pitt wrote:
>>> Hi Scott,
>>>
>>> Scott Ritchie [2008-12-15  2:22 -0800]:
>>>> After some discussion with a few core devs at UDS, I feel it is time to
>>>> formally propose that Wine be moved into main.
>>> Already discussed at UDS, but for the records: Support for (more or
>>> less) OOTB running windows applications has been one of my pet peeves,
>>> since many people asked me for how to convert their business over to
>>> free software, but were stuck on one particular Windows app. This
>>> indeed seems to be a blocker for acceptance.
>>>
>>> Besides the ia32-libs problem (which I'll comment on below), this by
>>> and large requires a firm commitment to maintaining wine. Would be
>>> great if you would be willing to do that full-time.
>>>
>>>> Moving Wine into Main (or whatever becomes of main with the archive
>>>> reorganization) will require a fair amount of work.  Most of Wine's
>>>> dependencies are already in main, but on amd64 Wine still requires
>>>> ia32-libs for about 15 packages that don't have separate lib32 versions.
>>> There is at least the theoretical possibility to only offer wine for
>>> i386 again, and provide a wrapper package on amd64 to set up an
>>> appropriate i386 dchroot and install wine in it.
>>>
>>>> I'd like to work on Wine in Ubuntu full time, however as a first step to
>>>> keep me busy I could easily spend a few months modifying these packages
>>>> to work properly in 32 bit mode on amd64.  This is work that will have
>>>> to be done eventually anyway, as 32 bit Windows applications are going
>>>> to be around for a long time.
>>> I disagree here. Changing source packages to build lib32foo packages
>>> on amd64 is a much better hack than the current ia32-libs package
>>> (which is EBW, not maintained well, not updated for security fixes,
>>> horribly brittle, and will make it to main only over my dead cold
>>> body). But lib32foo is a hack as well, and it utterly complicates
>>> packaging. I think the time for converting several dozen source
>>> packages could actually be spent much better with working on proper
>>> multiarch support (although this takes much more time).
>>>
>>> Having worked a bit on ia32-libs over the past years, I more and more
>>> came to the conclusion that the concept is flawed, and that nowadays
>>> people would be much better off with an i386 dchroot (with some tricks
>>> like bind-mounting /home) which can be kept up to date with security
>>> updates, and doesn't require constant intensive maintenance and source
>>> package changes.
>>>
>>> WDYT?
>>>
>> I'm worried about how this will work in the relatively near future when
>> Wine properly supports Win64 apps.  Win64 apps will need to interface
>> with Win32 apps, which means the wineserver will need to have access to
>> both 64 and 32 bit libraries simultaneously - I'm not sure that's
>> possible inside of a chroot.
> 
> That's a "chicken egg" problem. win64 needs win32 because there are no
> native 64bit apps for windows (at least not as much was win32 apps are
> on the market). It's the same "chicken egg" problem we have on 64bit
> Linux, because many of the "powerapps" (like flash e.g.) didn't have
> 64bit support.
> 
> Now, after many years of complaining to Adobe, <insert your fav closed
> source company>, we finally got a 64bit Linux version of Flash, Java
> Plugin or whatever. And hopefully more people will use more 64bit
> distros, and we can think in 5 years about dropping 32bit support
> completly.

No, we really can't, not even in 10 years.  There are tens of thousands
of 32 bit windows applications that will never be rewritten, and we'll
need to let users run them.  Many of Wine's current use cases are for 10
year old software; in another 10 years people will still want to use
software written today.

Now, it's quite possible that Wine and Windows applications will be the
only 32 bit only apps people actually want 10 years from now on Linux,
but even then we should still support it.

> 
> But right now, the demands for supporting 32bit apps on 64bit distro are
> high. That means we need to ship a complete set of 32bit libs (not only
> libs, but most likely complete 32bit packages of python{2.x,3.x} in our
> "beloved" ia32-libs package, which is insane (and that has nothing to do
> with wine).
> 

I absolutely agree with you here - transitioning to 64 bit has many
advantages, and we should especially do it with the open source programs
we have.

> Another way of dealing with the special wine "problem" would be, that
> the wine package itself is shipping the source and binary packages for
> the used 32bit libs, or that we have a "crazy" packager who starts now
> to add lib32* packages and build rules to all of the lib-packages (or we
> have multiarch support in no time), but this will take the same ammount
> of time, as it takes to drop 32bit support ,-)
> 

Hey I'm not THAT crazy ;)

> We need to find a sane solution for this, but always uploading a
> complete source package which has the size of an CD ISO Image for just
> adding another lib package because of appX doesn't have a 64bit version
> is a waste of bandwidth and is insane.

And whenever we figure out to make security updates for it, that's
another CD of downloads to push out to every user.

Thanks,
Scott Ritchie