The Debian packages have gotten rather out of date, and it looks like Ove's not going to be making them any more. I took the initiative and decided to try making one myself. I'm polishing off a new Debian package now.
Some major things I noticed:
1) There were a lot of old hacks in the package that are probably no longer necessary, due to advancements in wine like wineprefixcreate and such. There was also the remenants of a very old problem with compiling using flex (which I remember experiencing the old days) in the form of a special exception for installing newer flex packages.
2) Very old packages like winesetuptk should now be officially obsoleted by making them conflicted and replaced. I also did the same to the libwine-* packages that weren't doing anything but making documentation folders, like libwine-alsa.
3) Making my package looks to be a lot simpler than what's implied in the (now year out of date) package makers guide. I found that documentation quite useless (and didn't even find it until I was about half way done anyway). Again, this is probably due to advancements in wine itself.
4) What I didn't find is a standard list of packages that aren't strictly required for wine (like libxt-dev and flex), but that wine can benefit from. A good example would be the alsa development files. These are all things that should be included in the build dependencies for the package.
So far, my list of build dependant packages is the following: flex, bison, libx11-dev, libasound2-dev, libxt-dev, libicu28-dev
However, I'm not sure if this means the wine binary package should depend on them, since it's compiled in. So, should I make libicu28 a dependancy for wine?
Now, this leads to the question: is it worth even having a package maintainers guide? If so, who wants to update it?
Thanks, Scott Ritchie
Scott Ritchie wrote:
However, I'm not sure if this means the wine binary package should depend on them, since it's compiled in. So, should I make libicu28 a dependancy for wine?
ICU is compiled statically. There is no runtime dependency on libicu. It is an exception, however.
The general rule should be that the optional packages are build-dep, but only "suggested" or "Recommended" (I've never really managed to understand the difference between them) for the compiled result.
Shachar
On Tue, 2004-11-23 at 13:25 +0200, Shachar Shemesh wrote:
Scott Ritchie wrote:
However, I'm not sure if this means the wine binary package should depend on them, since it's compiled in. So, should I make libicu28 a dependancy for wine?
ICU is compiled statically. There is no runtime dependency on libicu. It is an exception, however.
The general rule should be that the optional packages are build-dep, but only "suggested" or "Recommended" (I've never really managed to understand the difference between them) for the compiled result.
Shachar
Recommended packages are also installed by default, suggested are not.
I decided to trudge through include/config.h and check to see which things aren't getting defined and then install the appropriate libraries (as well as put them in the build dependencies). It seems to be as simple as finding a comment like /* Define if you have the <gif_lib.h> header file. */, noting that it's commented out, and then searching for packages containing gif_lib.h on Debian's website, then adding them. In this case, there are two choices, giflib3g-dev and libungif4-dev. Investigating, it appears that giflib3g-dev is superior, since libungif4-dev was written to avoid the unisys patent, but both should work. I put a build-depend on either of those packages in the control file, and am off to the races.
On another note, is there a reason why giflib3g-dev isn't replacing libungif4-dev? I thought their patent expired, so giflib3g-dev can be free now.
Either way, I think I got all the packages wine can use that are available on Debian. I'll post my Include/configure.h file so someone can look through it and see if I'm missing something after it builds.
-Scott Ritchie
On Tuesday 23 November 2004 11:32, Scott Ritchie wrote:
- What I didn't find is a standard list of packages that aren't
strictly required for wine (like libxt-dev and flex), but that wine can benefit from. A good example would be the alsa development files. These are all things that should be included in the build dependencies for the package.
From documentation/PACKAGING:
------------------------------------------------------------------------
Here is a list of the soft dependencies. We suggest packagers install each and every last of those before building the package. These libraries are not dependencies in the RPM sense. In DEB packages, they should appear as "Suggests" or "Recommends", as the case may be. * FreeType: http://www.freetype.org This library is used for direct rendering of fonts. It provides better support of fonts than using the X11 fonts engine. It is only needed for the X11 back end engine. Used from GDI.
* Alsa: http://sourceforge.net/projects/alsa (Linux only) This library gives sound support to the Windows environment.
* JACK: http://jackit.sourceforge.net Similar to Alsa, it allow Wine to use the JACK audio server.
* CUPS: http://www.cups.org This library allows Windows to see CUPS defined printers.
* OpenGL This is used for both OpenGL and Direct3D (and some other DirectX functions as well) support in Wine. There are many many libraries for providing this functionality. It is enough for one of them to be available when compiling Wine. Wine can work with any other library during runtime. If no library is available, packagers are encouraged to compile Wine with Mesa3D (http://www.mesa3d.org), which requires no hardware support to install.
* LittleCMS: http://www.littlecms.com This library is used to implement MSCMS (Color Management System) which is needed by an increasing number of graphics applications.
On Tue, 23 Nov 2004, Hans Leidekker wrote: [...]
Alsa: http://sourceforge.net/projects/alsa (Linux only) This library gives sound support to the Windows environment.
JACK: http://jackit.sourceforge.net Similar to Alsa, it allow Wine to use the JACK audio server.
I would add NAS to that list for the winenas audio driver.
On Tue, 23 Nov 2004 02:32:08 -0800, Scott Ritchie wrote:
The Debian packages have gotten rather out of date, and it looks like Ove's not going to be making them any more. I took the initiative and decided to try making one myself. I'm polishing off a new Debian package now.
Cool! While you're at it could you please combine them altogether so the packaging matches the upstream sources? Last time I checked the Debian packages were split into tons of little packages which is wrong and led to strange breakages. Just one package with everything installed by "make install" in the sources would be great.
thanks -mike
On Tue, Nov 23, 2004 at 02:07:51PM +0000, Mike Hearn wrote:
Cool! While you're at it could you please combine them altogether so the packaging matches the upstream sources? Last time I checked the Debian packages were split into tons of little packages which is wrong and led to strange breakages. Just one package with everything installed by "make install" in the sources would be great.
Actually, a wine and wine-devel would be good, to match what we're doing with .rpm files. Reduces confusion. While you're at it, it would be nice to host them also on SF, so we have a one place that holds all the wine packages.
On Tue, 23 Nov 2004, Mike Hearn wrote: [...]
Cool! While you're at it could you please combine them altogether so the packaging matches the upstream sources? Last time I checked the Debian packages were split into tons of little packages which is wrong and led to strange breakages. Just one package with everything installed by "make install" in the sources would be great.
Having lots of packages is the Debian way. So I see nothing wrong with having wine, libwine, libwine-dev, wine-doc, libwine-alsa, libwine-arts, libwine-capi, libwine-cil, libwine-jack, libwine-nas, libwine-twain.
To those surprised by the -(alsa,arts,...) packages, this matches the xmms-(alsa,arts,...) packages. So there's nothing exceptional here.
I'm not sure about libwine-print. It pretty much only contains wineps.dll. I guess this is partly because of the CUPS dependency.
Also the wine-util package contains tools that I think belong to libwine-dev, especially winedbg, winedump and winemaker.
On Tue, 23 Nov 2004 19:14:00 +0100, Francois Gouget wrote:
Having lots of packages is the Debian way. So I see nothing wrong with having wine, libwine, libwine-dev, wine-doc, libwine-alsa, libwine-arts, libwine-capi, libwine-cil, libwine-jack, libwine-nas, libwine-twain.
Well, it may be the Debian way but it's not the Wine way.
I'm not saying this just to be pedantic, the fact that distros like Debian creatively ignore the way upstream is packaged caused me big problems when I wrote the IE installer script way back in January (which still gets ~300 hits a day). I assumed that if you had Wine installed, you'd have things like wineboot and regedit installed. These are shipped as part of Wine after all. But they weren't, Debian had classified them as optional utilities and my script broke. Gentoo had similar problems. I had to add in lots of hacks to make sure all the programs I used were there, and print out different messages for each distro giving the package name needed.
It's not just my script. Wine and Windows programs sometimes assume these applets are present too (eg notepad, wineboot, regedit, regsvr32).
The packaging on Red Hat/SuSE/Mandrake etc didn't have this problem because they mostly followed upstream conventions.
If this way of splitting everything up really is better we should split the Wine tarballs up into separate packages too. If it isn't then Debian should follow the upstream conventions, it would save people a lot of hassle debugging incomplete installs because some program tried to invoke regedit or notepad and it wasn't there.
To those surprised by the -(alsa,arts,...) packages, this matches the xmms-(alsa,arts,...) packages. So there's nothing exceptional here.
But why are they separate? What gain does this have? They're only loaded on demand if the user wants them anyway, having the drivers installed doesn't mean you actually have to have arts/alsa/nas installed.
Also the wine-util package contains tools that I think belong to libwine-dev, especially winedbg, winedump and winemaker.
winedbg for one is invoked by Wine directly when it crashes, I think it makes sense for it always to be present so useful remote debugging can occur.
thanks -mike
On Tue, Nov 23, 2004 at 07:14:00PM +0100, Francois Gouget wrote:
Having lots of packages is the Debian way. So I see nothing wrong with having wine, libwine, libwine-dev, wine-doc, libwine-alsa, libwine-arts, libwine-capi, libwine-cil, libwine-jack, libwine-nas, libwine-twain.
...and it creates a lot of problems: Patient: Doctor, it hurts when I do this... Doctor: Well, don't do it then.
To those surprised by the -(alsa,arts,...) packages, this matches the xmms-(alsa,arts,...) packages. So there's nothing exceptional here.
It is actually -- it is a stated goal in wine to actually unify all these drivers. We are introducing user-visible packages that are likely to go away. Very bad. If anything, we should *really* get rid of them.
I'm not sure about libwine-print. It pretty much only contains wineps.dll. I guess this is partly because of the CUPS dependency.
Clearly this one doesn't deserve a separate package. If the CUPS dep is a hard one, we should fix Wine, not propagate crap upstream.
Also the wine-util package contains tools that I think belong to libwine-dev, especially winedbg, winedump and winemaker.
Again, wine-util is looking for a purpose. Things should be split between wine, and libwine-dev. We should have: wine wine-doc libwine-dev (why not wine-devel? or wine-dev?)
at most.
On Tue, Nov 23, 2004 at 02:32:08AM -0800, Scott Ritchie wrote:
Now, this leads to the question: is it worth even having a package maintainers guide? If so, who wants to update it?
Well, it would be great if you'd use the experience you gathered doing the .deb packages to update the guide. Really, it can only be updated by a packager, someone that went through the motions. Moreover, the experienced packagers don't need that document as much, and are not likely to update it. So the only hope we have is for someone 'new' to the wine-packaging business to take on the job.
On Tue, Nov 23, 2004 at 10:47:47AM -0500, Dimitrie O. Paun wrote:
On Tue, Nov 23, 2004 at 02:32:08AM -0800, Scott Ritchie wrote:
Now, this leads to the question: is it worth even having a package maintainers guide? If so, who wants to update it?
I sat down for 15 minutes and revised it a bit. Open for comments.
Ciao, Marcus
I sat down for 15 minutes and revised it a bit. Open for comments.
Looks good to me. We may want to add a bit of a stronger warning at the top (maybe?) that the config file is obsolete, and will go away, so don't bother to customize or provide one. Right now it seems that our possition is a bit on the fence with respect to the config file which does not reflect well our intentions to get rid of it ASAP.
In fact, not having would be much better because it would teach users not to depend on it.
On Tue, Nov 23, 2004 at 05:16:17PM -0500, Dimitrie O. Paun wrote:
I sat down for 15 minutes and revised it a bit. Open for comments.
Looks good to me. We may want to add a bit of a stronger warning at the top (maybe?) that the config file is obsolete, and will go away, so don't bother to customize or provide one. Right now it seems that our possition is a bit on the fence with respect to the config file which does not reflect well our intentions to get rid of it ASAP.
Yes.
There is still one use for it I have found and needed, namely setting the Windows Version (I think for some Adobe program).
In fact, not having would be much better because it would teach users not to depend on it.
Yes.
Ciao, Marcus
Marcus Meissner wrote:
Here is a list of the soft dependencies. We suggest packagers install each and every last of those before building the package. These libraries are not dependencies in the RPM sense. In DEB packages, they should appear as "Suggests" or "Recommends", as the case may be.
ICU Adds support for BiDi to Wine. http://oss.software.ibm.com/icu/. Instructions for building (and testing) with BiDi are available at http://winehq.org/?issue=218#How%20To%20Set%20Up%20BiDi%20Support
Shachar
On Wed, 24 Nov 2004, Shachar Shemesh wrote:
Marcus Meissner wrote:
Here is a list of the soft dependencies. We suggest packagers install each and every last of those before building the package. These libraries are not dependencies in the RPM sense. In DEB packages, they should appear as "Suggests" or "Recommends", as the case may be.
ICU Adds support for BiDi to Wine. http://oss.software.ibm.com/icu/. Instructions for building (and testing) with BiDi are available at http://winehq.org/?issue=218#How%20To%20Set%20Up%20BiDi%20Support
The problem with ICU is that, iirc, it introduces a dependency on libstdc++, and, afaik, libstdc++ binary compatiblity is broken quite often.
This is probably not an issue for the Debian packages which we can expect to be rebuilt whenever a libstdc++ becomes the Debian standard. But it's a problem if one wants to build a somewhat generic RPM package that can be installed on anything from RedHat 8 to Fedora Core 3, or on RedHat, Mandrake and SUSE.
So if the Package Maintainer's guide recommends building with ICU, it should also mention this issue.
Francois Gouget wrote:
On Wed, 24 Nov 2004, Shachar Shemesh wrote:
Marcus Meissner wrote:
Here is a list of the soft dependencies. We suggest packagers install each and every last of those before building the package. These libraries are not dependencies in the RPM sense. In DEB packages, they should appear as "Suggests" or "Recommends", as the case may be.
ICU Adds support for BiDi to Wine. http://oss.software.ibm.com/icu/. Instructions for building (and testing) with BiDi are available at http://winehq.org/?issue=218#How%20To%20Set%20Up%20BiDi%20Support
The problem with ICU is that, iirc, it introduces a dependency on libstdc++, and, afaik, libstdc++ binary compatiblity is broken quite often.
This is probably not an issue for the Debian packages which we can expect to be rebuilt whenever a libstdc++ becomes the Debian standard. But it's a problem if one wants to build a somewhat generic RPM package that can be installed on anything from RedHat 8 to Fedora Core 3, or on RedHat, Mandrake and SUSE.
So if the Package Maintainer's guide recommends building with ICU, it should also mention this issue.
Sounds fair. I'll also mention that I'm working on moving the dependency out of the core wine functionality. I.e., if the dependency is not there, it's just BiDi that won't work.
Shachar
Actually, a wine and wine-devel would be good, to match what we're doing with .rpm files. Reduces confusion. While you're at it, it would be nice to host them also on SF, so we have a one place that holds all the wine packages.
-- Dimi.
Well, I am condensing it down. Here's what I think we should move towards with packaging:
wine : depends on libwine, contains the binaries for running windows programs libwine : contains everything needed to run windows applications libwine-dev : contains the files needed to compile windows applications with winelib
My reason for splitting off libwine and wine is that libwine can be installed without wine and could someday be used to launch a program that has been ported with winelib, without having to have wine proper in it.
I imagine someday I'll take an open source Windows program like eMule, set it up to compile with winelib, and have it turned into a Debian package. This way one could apt-get install emule and then have it depend on and install libwine, but not wine.
The reason for using libwine rather than winelib is to comply with Debian standards.
Thoughts?
On Tue, Nov 23, 2004 at 02:56:43PM -0800, Scott Ritchie wrote:
wine : depends on libwine, contains the binaries for running windows programs libwine : contains everything needed to run windows applications libwine-dev : contains the files needed to compile windows applications with winelib
There is no reason to split wine and libwine, they can not exist without each other. Trust me on this one, it will help no one to split the two.
The reason for using libwine rather than winelib is to comply with Debian standards.
Too bad, libwine is something different. This is confusing, I know, but probably the least problematic way forward would be to simply call it wine-dev.
On Tue, 23 Nov 2004 14:56:43 -0800, Scott Ritchie wrote:
My reason for splitting off libwine and wine is that libwine can be installed without wine and could someday be used to launch a program that has been ported with winelib, without having to have wine proper in it.
I'm afraid that's not correct. Due to C++ static constructor functions and address space layout issues you run winelib apps like so:
wine foo.exe.so
The reason for using libwine rather than winelib is to comply with Debian standards.
Well, no strong opinion on this, except a vague feeling that Wine upstream calls it winelib not libwine, and overriding upstream standards with downstream standards tends to cause confusion and pain at least in my experience. So I'd be tempted to go for winelib. It's not a real library anyway, you can't just dlopen it and go without a ton of complex work.
thanks -mike
Le mar 23/11/2004 à 05:32, Scott Ritchie a écrit :
The Debian packages have gotten rather out of date, and it looks like Ove's not going to be making them any more. I took the initiative and decided to try making one myself. I'm polishing off a new Debian package now.
Are you (or plan to be) a Debian developer (so your packages would replace Ove's in Debian system), or do you simply plan to provide those as a 3rd party?
Some major things I noticed:
- There were a lot of old hacks in the package that are probably no
longer necessary, due to advancements in wine like wineprefixcreate and such. There was also the remenants of a very old problem with compiling using flex (which I remember experiencing the old days) in the form of a special exception for installing newer flex packages.
- Very old packages like winesetuptk should now be officially obsoleted
by making them conflicted and replaced. I also did the same to the libwine-* packages that weren't doing anything but making documentation folders, like libwine-alsa.
libwine-alsa packaged winealsa.dll.so the last time I checked.
- Making my package looks to be a lot simpler than what's implied in
the (now year out of date) package makers guide. I found that documentation quite useless (and didn't even find it until I was about half way done anyway). Again, this is probably due to advancements in wine itself.
Wine as a whole is aiming to be self setupping, so less and less is required when building packages (other than providing a "good" build environment).
- What I didn't find is a standard list of packages that aren't
strictly required for wine (like libxt-dev and flex), but that wine can benefit from. A good example would be the alsa development files. These are all things that should be included in the build dependencies for the package.
As you found out already, check include/config.h for undefined vars. A lot are only there for compatibility between different core system files across Unix distributions, but you should be able to spot the ones depending on interesting libs.
So far, my list of build dependant packages is the following: flex, bison, libx11-dev, libasound2-dev, libxt-dev, libicu28-dev
I'm not sure you should put them as build dependancies. Wine can work without them. Sure, for you (when building the "official" ones) it's a good idea to have them installed on your system, but
Vincent
-
Dimitrie O. Paun -
Francois Gouget -
Hans Leidekker -
Marcus Meissner -
Mike Hearn -
Scott Ritchie -
Shachar Shemesh -
Vincent Béron