Wine packages, universe maintainence, and myself

[Vincent Béron]

Le sam 29/01/2005 à 20:49, Scott Ritchie a écrit :
> Hello,
> 
> I met some of you on IRC the other night. I am currently the Debian and
> Ubuntu packager for the Wine project. The "official" Debian maintainer
> hasn't been updating the packages and refuses to turn them over to me,
> so we've setup our own apt repository at winehq.org.

That's something you need to sort out through Debian, not Ubuntu nor
winehq. Each one of these projects have their own community and rules,
and even if some parts of them overlap, they're still different
entities.

Any attempt to use your position in one to force another one to your
liking will result in grumbling.

Moreover, you already know the steps to replace Ove as Debian's
maintainer: file bugs in Debian's bug system, then provide fixes for
them, one at a time. The only problem is you think that solution will
take too long to reach the goals you'd like. But it's the only way to
go. Any other way just won't work.

> The packages have
> been tested a lot, and are also in the Ubuntu backports project working
> fine. I was wondering what it would take to make them the ones that sit
> on Ubuntu's repository, rather than the (very old) Debian unstable ones,
> and from what I heard on IRC it seems like this is a rather doable thing
> for Ubuntu as we don't have to worry about Debian politics so much.  
> 
> Hence, I am writing this email.  I'd be willing to maintain the Wine
> packages for Ubuntu, as well as related ones such as winetools.  There's
> other work for me to do as well, but I suppose the first step is to
> coordinate things in here and make this happen.
> 
> There's quite a bit on my todo list for the moment
[snip]
> -The Winelib documentation needs updating as well.  I plan on using my
> experience trying to port Miranda IM to help it out.

Basically, look in past postings by Dimi when he was explaining the
reasoning behind winegcc (port first to mingw on Windows, then replace
gcc/g++/windres by winegcc/wineg++/wrc). Of course there are other
things to look for, for which winemaker is still suited (correct
#include "CaPiTaLiZaTiOn.h", line endings, etc.).

> -Winetools, a useful program for running Wine, also needs packaging.
> I've got it almost finished at this point, although I need some help
> with some issues I've been having.  More on this in IRC.
> 
> 
> As for the Wine package itself, the current versions of the Wine and
> Winetools packages are in my webspace, here:
> deb http://tuzakey.com/~scott/apt binary/ 
> deb-src http://tuzakey.com/~scott/apt source/ 
> 
> The Wine package at first glance seems a bit different from some Debian
> standards, for various reasons.
> 
> First off, even though Wine has some seemingly shared libraries, I
> haven't split them off.  This is because only wine binaries can really
> use them, and they need the latest version anyway.

They don't need "the latest" version, only a compatible version with the
one they were compiled against, at least until DLL separation is
completely sorted out (as well as probably other stuff I'm currently
forgetting about).

So if you install Miranda compiled against Wine 20050111, there's no
guarantee (for now, this should change after Wine 0.9) that the same
binary will work with Wine 200502?? or later.

Commercial projects using Winelib have shipped a version of Wine with
their software for this very reason (see Corel). It's something on the
todo list, but it's not done yet.

>  Both windows apps
> called with Wine and winelib apps still need to be handled by the same
> wineserver (in case they message eachother, amid other reasons), and so
> they are both completely dependent on the Wine binaries anyway.
> Furthermore, since it's the same wineserver coordinating everything on a
> system, it needs to have the same library in use - since it's basically
> impossible to get use out of more than one libwine.so.x in a system, it
> makes little sense to support this.

No problem doing so with various LD_LIBRARY_PATH... Even doing so in
pre-packaged binaries is much doable (look at Crossover Office and
Cedega).

> 
> Secondly, Wine, not being an emulator, has some rather important
> differences between architectures.  Wine really does need 3 different
> packages for the 3 different Ubuntu arches, as they each have some
> challenges.  The i386 one is the simplest, and is basically standard
> Wine.  The PPC arch can only run winelib apps, so it may need some
> trimming down and added documentation to prevent confusion.  The 64 bit
> version of Wine represents the most interesting challenge, as Wine will
> still need the old 32 bit libraries to run 32 bit Windows applications.
> According to forum posts I've read, Wine packages not currently doing
> this easily is actually a blocker for some users in switching to 64 bit
> Ubuntu.

Use the 32bit package on 64bit Ubuntu (you'll need 32bit libraries as
well). It's the only way to go for now. If the package management tools
can't handle this, at least know that the files in both the 32bit and
64bit packages will be the same if you do a plain ./configure on a
x86-64 computer.

Unless I don't understand what you mean by "different packages"...

> 
> Wine has some rather unique things which make it harder to maintain.
> -Arch issues, like mentioned above
> -PAX issues will inevitably come up again. This was an issue that came
> up before, although with Ubuntu using the latest Wine it will certainly
> be an easier one to tackle.

More Ubuntu/PAX users developing Wine would help on finding and fixing
more quickly those. But you can't force people to use a certain
distribution...

[snip]

Vincent