ia32-libs [was: Bringing Wine into Main]

Stephan Hermann sh at sourcecode.de
Thu Dec 18 08:06:00 GMT 2008


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

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).

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 ,-)

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.



More information about the ubuntu-devel mailing list