Call to all packagers (especially Debian)
It seems there is no end to how far will packagers go to brake Wine by trying to make it better I thought it's been fixed a long time ago, but it seems not. Wine packages for Debian split important Wine parts into separate packages: - wine - fonts, few not essential programs, symlinks and _premade_ content of ~/.wine directory (with ~/.wine/c as default c: drive)!!! - libwine - all the builtin dlls - wine-utils:(explorer, winecfg, winepath, cmd.exe, iexplore, winedbg) and many other packages. Also as default it's using "winelauncher" instead of standard "wine" binary. That makes it that much more complicated to troubleshoot any problems that users might have. So in case anyone having problems with Debian or Debian based distro, please check that all the "*wine*" packages installed. Also is there a way we can request packagers to follow some standard to how they package Wine? Can we ask packagers to package all parts of Wine into one single package? If they prefer, they can package optional sound drivers separately (arts, esd, jack, nas). Same for documentation, and development headers. However everything else is essential to Wine and most programs that ran under it. Also can packagers keep default method of starting Wine the same without using any additional scripts for starting Wine? And of course, if any alterations has been made, state so in the distro specific readme file. Of course I realize that this is open source and anyone can do whatever they pleased. But please, that's make it more supportable. It's such a huge PITA to waste several hours trying to find the reason why something doesn't work to realize that person doesn't have explorer. Needless to say that lots of things won't work right. Vitaliy.
On Sunday 26 November 2006 03:36, Vitaliy Margolen wrote:
It seems there is no end to how far will packagers go to brake Wine by trying to make it better
I thought it's been fixed a long time ago, but it seems not. Wine packages for Debian split important Wine parts into separate packages: - wine - fonts, few not essential programs, symlinks and _premade_ content of ~/.wine directory (with ~/.wine/c as default c: drive)!!! - libwine - all the builtin dlls - wine-utils:(explorer, winecfg, winepath, cmd.exe, iexplore, winedbg) and many other packages.
Hmm, wine depends on libwine and recommends wine-utils. Since most people install "recommends" as well (aptitude does this), what would be those "many other packages" that are essential for a full featured wine? Maybe it's not clear to the Debian packager that they should be in "recommends" or at least "suggests". Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
Hello
Hmm, wine depends on libwine and recommends wine-utils. Since most people install "recommends" as well (aptitude does this), what would be those "many other packages" that are essential for a full featured wine? Maybe it's not clear to the Debian packager that they should be in "recommends" or at least "suggests".
I've just checked this against gentoo, there's also no dependency on xdg-utils. I shall post an ebuild update request to the gentoo-bugzilla. -- Pozdrawiam Wojciech Arabczyk :: http://www.arabek.net :: jid:arab(a)chrome.pl Administrator: http://www.szluug.org & http://www.trron.pl
On 26 nov. 06, at 03:36, Vitaliy Margolen wrote:
And of course, if any alterations has been made, state so in the distro specific readme file.
I think that to have a better view of those alterations the packaging utilities (package spec files and other supporting tools) should be opensource-ed. It would be great to have a repository which contains everything needed to build the official Wine packages for each distribution. That would allow have a better transparency on how the maintainers make their packages. Also it means probably a better level of flexibility given that any one could customize its package, and build it with on top of whatever wine version one likes. The package release latency after a Wine release may diminish too. A first step would be to have each maintainer putting in the wiki their howto build the Debian/Ubuntu/... package from scratch. I have in mind what has been done for the Mac OS X package [1]. A second step would be to move spec files, scripts and such to a cvs or git repository like what is in place for the winehq website and documentation. Tell me what you think, Pierre. [1] http://wiki.winehq.org/MacOSX/Building
On Sat, 2006-11-25 at 19:36 -0700, Vitaliy Margolen wrote:
It seems there is no end to how far will packagers go to brake Wine by trying to make it better
I thought it's been fixed a long time ago, but it seems not. Wine packages for Debian split important Wine parts into separate packages: - wine - fonts, few not essential programs, symlinks and _premade_ content of ~/.wine directory (with ~/.wine/c as default c: drive)!!! - libwine - all the builtin dlls - wine-utils:(explorer, winecfg, winepath, cmd.exe, iexplore, winedbg) and many other packages. Also as default it's using "winelauncher" instead of standard "wine" binary. That makes it that much more complicated to troubleshoot any problems that users might have.
So in case anyone having problems with Debian or Debian based distro, please check that all the "*wine*" packages installed. Also is there a way we can request packagers to follow some standard to how they package Wine?
Can we ask packagers to package all parts of Wine into one single package? If they prefer, they can package optional sound drivers separately (arts, esd, jack, nas). Same for documentation, and development headers. However everything else is essential to Wine and most programs that ran under it.
Also can packagers keep default method of starting Wine the same without using any additional scripts for starting Wine?
And of course, if any alterations has been made, state so in the distro specific readme file.
Of course I realize that this is open source and anyone can do whatever they pleased. But please, that's make it more supportable. It's such a huge PITA to waste several hours trying to find the reason why something doesn't work to realize that person doesn't have explorer. Needless to say that lots of things won't work right.
Vitaliy.
This is precisely why I started making the packages myself (that and they were always about 3 months out of date in Debian). I tried to get my packages put into Debian but after investing about 20 hours of work into it simply gave up. I ran into a huge wall of Debian-orchestrated bureaucracy: the packages are split in this broken way as "policy", I need to file a separate bug report against the package for each application that breaks (and each debian-specific change that does no good), nobody could upload my current version of the package since only the official maintainer can make a non-security fix, and all sorts of other needless headaches. Ubuntu, on the other hand, accepted my packages with open arms. So now I run and package for Ubuntu, and from what I hear my packages work on Debian. Really, we should set up a wiki or web page for Debian users telling them the whole story. As you've noticed, it really is annoying troubleshooting this issue when it's so frequently Debian's fault and there's nothing we can do about it other than tell users that Debian is messed up. I'd really hate to have to go back to the days where we told users to compile Wine themselves. Thanks, Scott Ritchie
Vitaliy Margolen wrote about Debian packaging:
It seems there is no end to how far will packagers go to brake Wine by trying to make it better [...] Also as default it's using "winelauncher" instead of standard "wine" binary. That makes it that much more complicated to troubleshoot any problems that users might have.
Could you (or someone else) explain why is it bad to use "winelauncher"? We don't currently use it in the Mandriva packaging of wine, but a request just got opened asking us to use "winelauncher" instead of "wine": http://bugzilla.mandriva.com/show_bug.cgi?id=27638 Thanks, -- Anssi Hannula
Anssi Hannula wrote: > Vitaliy Margolen wrote about Debian packaging: >> It seems there is no end to how far will packagers go to brake Wine by >> trying to make it better > [...] >> Also as default it's using "winelauncher" >> instead of standard "wine" binary. That makes it that much more >> complicated to troubleshoot any problems that users might have. > > Could you (or someone else) explain why is it bad to use "winelauncher"? There are number of reasons: 1. It outputs different information from normal "wine" command. This is confusing to user as well as person who trying to debug the problem. 2. It's hard-coded to the default WINEPREFIX. More and more users starting to use other prefixes for testing purposes or just to separate applications. 3. It's not well maintained. 4. It does not work with wine from source directory or custom "wine" scripts. I don't have Wine installed but I have custom ~/bin/wine script. The winelauncher was unable to find nor start wine properly in this configuration. And possibly number of other problems that I don't know about. > We don't currently use it in the Mandriva packaging of wine, but a > request just got opened asking us to use "winelauncher" instead of "wine": > http://bugzilla.mandriva.com/show_bug.cgi?id=27638 What bug reporter seems to ask is to add "wine" and possibly "winecfg" entries to the WM's menu. That is something you can do with provided xpm icon and pre-made wine.desktop link. That link should also take care of associating Wine with at least *.exe files. Also it might be because until few versions back, Wine was able to create menu entries for KDE users only. Oh and also looking at winelauncher, it doesn't create the links bug reporter asks for. Vitaliy.
participants (6)
-
Anssi Hannula -
Kevin Krammer -
Pierre d'Herbemont -
Scott Ritchie -
Vitaliy Margolen -
Wojciech 'arab' Arabczyk