Wine packages, universe maintainence, and myself
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. 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 -Documentation is a seemingly never-ending task, both for man pages and packaging guidelines and such. -The Wine documentation also needs to be moved into the right places. I was recently given a very helpful tip on IRC about making Wine's User Guide work with standard freedesktop.org help interfaces, and I'll be committing the patch upstream shortly. -Tweaking the wine package to get it a bit more right is also important. I've got a bunch of little changes I need to make for the next release written up on my penboard at the moment. Hopefully soon I can start erasing them. -Updating the Wine User Guide itself. I've already got chapter 1, the introduction, finished. Obviously, this is a good thing to do. -Updating the Wine web site to make things easier (example is this page: http://www.winehq.org/site/download-deb ). That site may undergo a slight redesign in the future too. -I've got a special project I've been trying for a while involving porting Miranda Instant Messenger with Winelib. In theory, I could convert it into an Ubuntu package that runs on all arches with the Wine package installed, even though Miranda is a windows program. If this becomes easy it represents an amazingly huge step in application compatibility - it won't be long before we start seeing other OSS apps like DC++ or FileZilla coming into Ubuntu packages. Writing a howto guide for this based on my experience is part of this goal. -The Winelib documentation needs updating as well. I plan on using my experience trying to port Miranda IM to help it out. -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. 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. 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. 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. -Until Wine hits a stable release, which seems to be perpetually six months away, Wine is updated monthly. This means an old and possibly unstable version of Wine will perpetually end up in Universe, unless we backport it. This may or may not be a problem from the User's perspective. Either way, I'll make the latest available at winehq.org. Clearly the best long term solution is to move to a more stable Wine release - I've been doing my part to help clear our 0.9 blocker bugs like the lack of documentation, but I can't do much for core Wine development other than cheer on my compatriots. We may want to have an entirely new applications menu for Wine. I envision having Wine installed and then having it create a new folder Applications->Wine, which will contain the Winecfg program labeled "Configure Wine" as well as a near empty start menu with Wine's shipped winelib Notepad program. When other windows programs get installed, they can be put in the Wine start menu there. The PPC arch may have no real need of start menu, though. We can run winelib apps on ppc, such as the hypothetical Miranda-IM package, but it might make sense to put that somewhere other than Wine's start menu (such as Applications->Internet) In fact, we may want to have packaged winelib apps specifically not go in the Wine folder for all arches, even arches that support a Wine start menu. I guess I should make a page for myself on the Ubuntu wiki. I'll likely put a huge todo list for myself up there as well, if for no other reason than to remind me of what I still want to do. I really like what's going on with Ubuntu. Most encouraging are emails I get like the following: ----------------- Dear Scott, I am using your wine packages from: deb http://wine.sourceforge.net/apt/ binary/ deb-src http://wine.sourceforge.net/apt/ source/ and it's just great! Thank you! It would be way cool if your packages could be the official Debian ones. I sincerely hope that some solution can be found, so that it can happen. Best regards, Silvestre ----------------- I also had a man message me on AIM thanking me profusely for the Wine packages. Apparently he had won several hundred dollars using a Windows poker program via Wine. The ability of Wine to put usable icons on the desktop really impresses users, and I really look forward to the day when we can have a usable start menu too. Anyway, I'd appreciate feedback and thoughts about this, as well as help with my package. Meet me in IRC, I'm YokoZar. Thanks, Scott Ritchie
On Sat, 29 Jan 2005 17:49:01 -0800, Scott Ritchie <scott(a)open-vote.org> wrote:
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.
Anyone willing to maintain packages gets my vote. Thumbs up.
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.
Speaking as a non-Debian user, that looks good to me. I hate how you can otherwise have lots of little library packages that are otherwise worthless because they must be used together.
We may want to have an entirely new applications menu for Wine. I envision having Wine installed and then having it create a new folder Applications->Wine, which will contain the Winecfg program labeled "Configure Wine" as well as a near empty start menu with Wine's shipped winelib Notepad program. When other windows programs get installed, they can be put in the Wine start menu there.
It is on my system...
I also had a man message me on AIM thanking me profusely for the Wine packages. Apparently he had won several hundred dollars using a Windows poker program via Wine.
I'll have to make a note not to try that out - I don't need any more excuses for wasting time. On that note, I'm going to Vegas next week. I plan on bringing down the house, retiring, and buying a small Caribbean island.
Anyway, I'd appreciate feedback and thoughts about this, as well as help with my package. Meet me in IRC, I'm YokoZar.
-Brian ("vinn")
On Sat, 29 Jan 2005 17:49:01 -0800, Scott Ritchie wrote:
We may want to have an entirely new applications menu for Wine. I envision having Wine installed and then having it create a new folder Applications->Wine, which will contain the Winecfg program labeled "Configure Wine" as well as a near empty start menu with Wine's shipped winelib Notepad program. When other windows programs get installed, they can be put in the Wine start menu there.
FWIW the GNOME HIG recommends stating what something is, rather than it's name. This makes sense because to a new Linux user the name "Wine" is meaningless, the fact that it's a cute abbreviation for Windows Emulator or "Wine is not an emulator" (depending on whether you read Slashdot) isn't obvious at all. So I think it'd make more sense to put a launcher called "Configure Windows Emulation" in the System tools/System settings menu, rather than give it a dedicated menu. We should do this in the upstream sources rather than have it be an Ubuntu specific patch. On menu integration: this is hard. Really hard. You do not want to know about the contortions we go through in Crossover to make it work. It's simpler for WineHQ because we can tell anybody not using bleeding-edge desktops that they lose, but even so I'd suggest starting by fixing the current menu code to write out .desktop files with a special category "Win32", and dumping them in ~/.local/share/applications or wherever they're supposed to go. That way you'd get all the Windows start menu items in one submenu. You lose the tree structure but that's not as big a deal as you may think, because a nearly empty start menu looks a bit weird and most of the time I guess Wine users will have one or two apps installed. You may need to wait for Hoary for this to work, as the current stable release of GNOME doesn't understand XDG menus which is the spec we must target. The unstable/development GNOME in Hoary does understand it. Oh, remember to make the .desktop files use the start.exe program ... some apps need that and it's an easy fix! Final thing, we need a nice icon for win32 EXE files. I filed a bug against gnome-icon-theme (really we want it in hicolor so non-GNOME users get it too) but Jimmac is a busy busy man ... thanks -mike
On Sunday 30 January 2005 14:00, Mike Hearn wrote:
Final thing, we need a nice icon for win32 EXE files. I filed a bug against gnome-icon-theme (really we want it in hicolor so non-GNOME users get it too) but Jimmac is a busy busy man ... KDE's default theme (CrystalSVG) already has an exec_wine icon. I think it's worth to make the icons have the same name so that uses of different environments can make use of different icons (KDE should look inside the current selected theme, then in his default theme, then in hicolor, then in locolor, so if it finds the icon in his themes, it doesn't go look in the hicolor one).
-- Diego "Flameeyes" Pettenò flameeyes(a)users.berlios.de - http://flameeyes.web.ctonet.it/
titta här: Scott Ritchie wrote: <snip>
-I've got a special project I've been trying for a while involving porting Miranda Instant Messenger with Winelib. In theory, I could convert it into an Ubuntu package that runs on all arches with the Wine package installed, even though Miranda is a windows program. If this becomes easy it represents an amazingly huge step in application compatibility - it won't be long before we start seeing other OSS apps like DC++ or FileZilla coming into Ubuntu packages. Writing a howto guide for this based on my experience is part of this goal.
Inte så dumt eller hur?
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
On Sun, 30 Jan 2005 17:57:20 -0500, Vincent Béron wrote:
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.
Hmm, I think it's fine for Scott to just work around Debian here. There's no guarantee that just filing bugs one at a time will achieve anything, right? While it is rather tempting to just say that Debian should sort themselves out, unfortunately we still end up with random users running bad packages so we get to pick up the pieces. I'd rather Scott provided better packages even if it's not a part of Debian officially.
-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...
Well, it's all a bit controversial isn't it. I'm absolutely not convinced PaX reveals "bugs": so far on the list of things it breaks are such fundamental programs as OpenGL and the Nautilus file manager. I for one don't care much right now if Wine is on that list too, given that I don't see how you can have a modern desktop with it enabled ... thanks -mike
participants (6)
-
Brian Vincent -
Diego 'Flameeyes' Pettenò -
Jakob Eriksson -
Mike Hearn -
Scott Ritchie -
Vincent Béron