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