ia32-libs [was: Bringing Wine into Main]

[Mark Syms]

> 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.
>
> 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.
>
> Regards,
>
> \sh

Speculative suggestion, is an update to apt/dpkg feasible such that and64
and i386 repos are known to "be related". So if something wants the 32 bit
version of a library it is pulled from the i386 repo and then transformed
on the fly so that libs are installed into lib32?

Just a random thought.

Mark.