ia32-libs [was: Bringing Wine into Main]

[Stephan Hermann]

Moins,


On Wed, 2008-12-17 at 11:08 +0100, 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.

I don't think this will happen at any time...wine 1.0 needed 15 years of
work of people...and if wine wants to support all apps on the windows
market...how many years we will work on that?

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

This was/is an old idea, since we discussed wine32 on amd64, and all
people who were involved said: "No, this is too difficult for the users"
But I think it's the only sane way to come around this monster of
ia32-libs.


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

When you look at the bug reports on ia32-libs source pkg, you can see,
that more and more people want to have more and more 32bit libs included
into this source pkg monster. Right now, nobody (exclude Martin and the
other paid-devs and sometimes myself and mostly all people with enough
upload bandwidth power) is really able to upload the ia32-libs source
package. 
That said, all the wishes from users are ok, if there is a sane way to
maintain this package for other people mentioned above (but shipping a
complete python2.5 i386 package in ia32-libs just for libpython2.5 is a
bit crazy, see
https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/277454)

And TBH, the i386 dchroot way is more sane for us, and if we provide a
simple user interface for that (this could also be a simple shell script
or whatever) it would help us more then adding more and more crap to
ia32-libs.

> WDYT?
> 

Full Ack on your proposal.

Regards,

\sh