Wine packages, universe maintainence, and myself

Shimon shimen at gmail.com
Mon Jan 31 00:07:15 CST 2005


wine is all nice but it doesn't have GTK+ buildings which is a big hold back...


On Sun, 30 Jan 2005 12:26:01 -0800, Scott Ritchie <scott at open-vote.org> wrote:
> 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
> 
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> http://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
> 


-- 
>From the desk of shimon.



More information about the ubuntu-devel mailing list