It seems that FC5 packager created a broken Wine distribution.
Instead of being 1-3 packages it's 15 (from what user told me on #winehq. And it doesn't work at all: "Application tried to create a window, but no driver could be loaded."
Which tells me it's compiled without X headers. I didn't even new Wine could compile without X, since we don't have tty driver.
Vitaliy
On Sat, 10 Jun 2006 17:31:22 -0600 Vitaliy Margolen wine-devel@kievinfo.com wrote:
It seems that FC5 packager created a broken Wine distribution.
I don't think I did... ;)
Instead of being 1-3 packages it's 15 (from what user told me on #winehq. And it doesn't work at all: "Application tried to create a window, but no driver could be loaded."
Yes it is (ok more like 11 but ok). For me it works for the programs it should work on...
Which tells me it's compiled without X headers. I didn't even new Wine could compile without X, since we don't have tty driver.
Be sure it is compiled with everything that FC/FE{3,4,5,devel} can support. The only thing is that some stuff is split out into subpackages and if users want that support they need to install it. Take a look at debian for example. Fedora Extras wine layout is basically the same. For the X driver... that should work out of the box so I suspect that the user has a different problem. In any way direct FE wine users to http://bugzilla.redhat.com to file bug against wine. This way I can easily track such bugs and decide if they should be filed against wine or if it really is a packaging but.
- Andreas
On Sun, 11 Jun 2006 11:09:10 +0200, Andreas Bierfert wrote:
Yes it is (ok more like 11 but ok). For me it works for the programs it should work on...
We had this problem with Debian, where people didn't install the "utils" package and apps broke mysteriously. Unless you have a lot of experience of Wine debugging you cannot detect this easily ... please, there's no reason to split this stuff up as Wine will load everything in a failsafe fashion so there is no need to mark the package as depending on a million things.
Out of interest what are the 11 packages?
thanks -mike
On Sun, 11 Jun 2006 21:39:30 +0100 Mike Hearn mike@plan99.net wrote:
We had this problem with Debian, where people didn't install the "utils" package and apps broke mysteriously. Unless you have a lot of experience of Wine debugging you cannot detect this easily ... please, there's no reason to split this stuff up as Wine will load everything in a failsafe fashion so there is no need to mark the package as depending on a million things.
Well from a wine perspective I see that this makes sense, but if you take a look at all the dependencies it is another story... installing wine is one thing... ending up with zillion dependencies is a whole different story for lots of people where e.g. bandwidth is still a problem or which rather want to have a slim system. I as a packager sit between the chairs and in this case I see why splitting up wine made sense in debian and why it made sense for Fedora Extras as well. The question is what to split and what to leave in. The stuff that has been split from just having one 'wine' package is stuff that made sense and in ways interacts best with what Fedora Core ships with the distro. Sure there are improvements to be made and suggestions are always welcome :) but doing it the way it is done now made lots of people happy (and gave me positive feedback).
Out of interest what are the 11 packages?
wine wine-arts wine-capi wine-cms wine-esd wine-jack wine-ldap wine-nas wine-tools wine-twain
These are the 10 packages which are relevant for a 'normal' user where wine and wine-tools are the major ones. They are build from the wine sources (without winemp3). Then there is:
wine-debuginfo wine-devel
These two are more or less only interesting for packagers/developers etc.
For more details take a look here: http://cvs.fedora.redhat.com/viewcvs/rpms/wine/FC-5/?root=extras
And of course build from the wine-docs sources is the wine-docs rpm: wine-docs
http://cvs.fedora.redhat.com/viewcvs/rpms/wine-docs/?root=extras
thanks -mike
no problem.
- Andreas
On Monday 12 June 2006 00:03, Andreas Bierfert wrote:
For more details take a look here: http://cvs.fedora.redhat.com/viewcvs/rpms/wine/FC-5/?root=extras
Why is there no BuildRequires for freetype? gphoto2? We also have a soft dependency on glibc-devel for dns resolver support. gcc depends on glibc-devel so you maybe you don't need to list it explicitly. On the other hand you do list zlib-devel. Does Wine directly depend on it?
-Hans
On Mon, Jun 12, 2006 at 11:29:32AM +0200, Hans Leidekker wrote:
On Monday 12 June 2006 00:03, Andreas Bierfert wrote:
For more details take a look here: http://cvs.fedora.redhat.com/viewcvs/rpms/wine/FC-5/?root=extras
Why is there no BuildRequires for freetype? gphoto2? We also have a soft dependency on glibc-devel for dns resolver support. gcc depends on glibc-devel so you maybe you don't need to list it explicitly. On the other hand you do list zlib-devel. Does Wine directly depend on it?
zlib is needed for freetype2. perhaps it is missing in freetype2-devel.
Ciao, Marcus
On Mon, 12 Jun 2006 00:03:23 +0200, Andreas Bierfert wrote:
Well from a wine perspective I see that this makes sense, but if you take a look at all the dependencies it is another story...
This is a problem with RPM and not with Wine. If RPM/yum had the concept of optional dependencies like some other systems do then this would really not be an issue. A better way to handle this would be to fix RPM, or simply to not mark them as dependencies at all yet still build the package with those features enabled. If the supporting libraries are missing the features will be disabled at runtime usually with a message on stderr.
The problem here is exactly the same as with Debian. This approach is just broken and should not be used. What if the user does not know about wine-tools and does not install it? They will be missing:
* winecmd * notepad * winedbg * winepath * winhelp * _EXPLORER_
These may appear to to be optional but they are not.
Explorer is needed for shell integration, HAL support and system tray support. It is not an end user tool, it's a part of the Wine infrastructure.
Winedbg is needed to produce useful crash data for developers. Notepad and winecmd are sometimes used by installers which will *fail silently* if they are missing. Winepath is used by various third party scripts. Winhelp is used by apps for online help, obviously.
Gah. This is just frustrating. The same mistakes are made over and over and over again. And we are the ones who get to pick up the bugs. What was wrong with the way Vincent did it?
-m
On Mon, 12 Jun 2006 15:31:12 +0100 Mike Hearn mike@plan99.net wrote:
On Mon, 12 Jun 2006 00:03:23 +0200, Andreas Bierfert wrote:
Well from a wine perspective I see that this makes sense, but if you take a look at all the dependencies it is another story...
This is a problem with RPM and not with Wine. If RPM/yum had the concept of optional dependencies like some other systems do then this would really not be an issue. A better way to handle this would be to fix RPM, or
It does know about this (don't quite remember the version it was introduced with but it allows for that now).
simply to not mark them as dependencies at all yet still build the package with those features enabled. If the supporting libraries are
This is just wrong packaging. Sorry if this sounds harsh but that cannot be the solution and it never will be in Fedora Extras.
missing the features will be disabled at runtime usually with a message on stderr.
Don't get me wrong... I am really happy that in the near future (1-2 years) rpm and yum support for optional dependencies will be spread enough so it solves a lot of issues like this one and I am really happy to make use of it... but for now this is not an option, sadly...
The problem here is exactly the same as with Debian. This approach is just broken and should not be used. What if the user does not know about
Hm maybe it is... but then I am no wine crack... splitting stuff up is something you do in packaging and what really is encouraged by distributions. Splitting stuff makes users happy and I can see why... ;) Looking over to debian and thinking about the stuff that is installed by 'make install' got me to the layout I have now... I don't say its perfect... it never was and it probably never will be... that is why I like input from upstream... I am the packager not the guy who did all the work on wine but I am the packager and I know what is needed/wanted/regulated on the fedora side of the story. Together with your input I am more than happy to change things around, just need people upstream who are willing to listen and talk to packagers and I hope in this case it will work. On thing I could offer which probably makes sense anyway is to mention sub packages in the description or in a README-Fedora.
wine-tools and does not install it? They will be missing:
- winecmd
- notepad
- winedbg
- winepath
- winhelp
- _EXPLORER_
These may appear to to be optional but they are not.
Explorer is needed for shell integration, HAL support and system tray support. It is not an end user tool, it's a part of the Wine infrastructure.
Ok, will move explorer to the main wine package.
Winedbg is needed to produce useful crash data for developers. Notepad and winecmd are sometimes used by installers which will *fail silently* if they are missing. Winepath is used by various third party scripts. Winhelp is used by apps for online help, obviously.
hm then maybe stuff should be merged to the main wine package for the stuff mentioned above... will look into it and if you have further input and suggestions rest assured that they are always welcome.
Gah. This is just frustrating. The same mistakes are made over and over and over again. And we are the ones who get to pick up the bugs. What was wrong with the way Vincent did it?
Well for one thing: Direct them to me or https://bugzilla.redhat.com. I have no problem with that and I stand for what I do. Maybe just maybe try to see the packager/distro side of things and you will see that what Vincent did was great work and is for certain things but for what is modern packaging and very distribution specific to fedora or even fedora extras the way I did it is the way to go... not by my opinion but the opinion and rules of the fedora community... if you don't like it fine... ignore it, ignore me... but I'd rather work together with you and the wine team on improving the wine experience for users and not fighting here wasting time that could be better spent improving the user situation.
- Andreas
Tuesday, June 13, 2006, 1:14:00 AM, Andreas Bierfert wrote:
On Mon, 12 Jun 2006 15:31:12 +0100 Mike Hearn mike@plan99.net wrote:
On Mon, 12 Jun 2006 00:03:23 +0200, Andreas Bierfert wrote:
Well from a wine perspective I see that this makes sense, but if you take a look at all the dependencies it is another story...
simply to not mark them as dependencies at all yet still build the package with those features enabled. If the supporting libraries are
This is just wrong packaging. Sorry if this sounds harsh but that cannot be the solution and it never will be in Fedora Extras.
And why isn't that a solution? That's what Wine already _does_. So what is the problem on your end? Just a principle?
missing the features will be disabled at runtime usually with a message on stderr.
Don't get me wrong... I am really happy that in the near future (1-2 years) rpm and yum support for optional dependencies will be spread enough so it solves a lot of issues like this one and I am really happy to make use of it... but for now this is not an option, sadly...
Obviously you have never monitored this mailing list, looked at the source, bothered reading documentation. But that has nothing to do with rpm/deb/etc. That the the way Wine is made. It is built with few hard requirements. Most are soft requirements.
wine-tools and does not install it? They will be missing:
- winecmd
- notepad
- winedbg
- winepath
- winhelp
- _EXPLORER_
These may appear to to be optional but they are not.
Explorer is needed for shell integration, HAL support and system tray support. It is not an end user tool, it's a part of the Wine infrastructure.
Ok, will move explorer to the main wine package.
You totally missed the point. You have to include _all_. Otherwise one part of Wine or another will brake. That's the main reason why I said that these packages are broken and that anyone reading this list should stay away from them.
The only parts that you can possibly split are sound drivers, headers and debug package.
Vitaliy
Andreas Bierfert wrote:
On Mon, 12 Jun 2006 15:31:12 +0100 Mike Hearn mike@plan99.net wrote:
On Mon, 12 Jun 2006 00:03:23 +0200, Andreas Bierfert wrote:
Well from a wine perspective I see that this makes sense, but if you take a look at all the dependencies it is another story...
This is a problem with RPM and not with Wine. If RPM/yum had the concept of optional dependencies like some other systems do then this would really not be an issue. A better way to handle this would be to fix RPM, or
It does know about this (don't quite remember the version it was introduced with but it allows for that now).
simply to not mark them as dependencies at all yet still build the package with those features enabled. If the supporting libraries are
This is just wrong packaging. Sorry if this sounds harsh but that cannot be the solution and it never will be in Fedora Extras.
missing the features will be disabled at runtime usually with a message on stderr.
Don't get me wrong... I am really happy that in the near future (1-2 years) rpm and yum support for optional dependencies will be spread enough so it solves a lot of issues like this one and I am really happy to make use of it... but for now this is not an option, sadly...
The problem here is exactly the same as with Debian. This approach is just broken and should not be used. What if the user does not know about
Hm maybe it is... but then I am no wine crack... splitting stuff up is something you do in packaging and what really is encouraged by distributions. Splitting stuff makes users happy and I can see why... ;) Looking over to debian and thinking about the stuff that is installed by 'make install' got me to the layout I have now... I don't say its perfect... it never was and it probably never will be... that is why I like input from upstream... I am the packager not the guy who did all the work on wine but I am the packager and I know what is needed/wanted/regulated on the fedora side of the story. Together with your input I am more than happy to change things around, just need people upstream who are willing to listen and talk to packagers and I hope in this case it will work. On thing I could offer which probably makes sense anyway is to mention sub packages in the description or in a README-Fedora.
wine-tools and does not install it? They will be missing:
- winecmd
- notepad
- winedbg
- winepath
- winhelp
- _EXPLORER_
These may appear to to be optional but they are not.
Explorer is needed for shell integration, HAL support and system tray support. It is not an end user tool, it's a part of the Wine infrastructure.
Ok, will move explorer to the main wine package.
Winedbg is needed to produce useful crash data for developers. Notepad and winecmd are sometimes used by installers which will *fail silently* if they are missing. Winepath is used by various third party scripts. Winhelp is used by apps for online help, obviously.
hm then maybe stuff should be merged to the main wine package for the stuff mentioned above... will look into it and if you have further input and suggestions rest assured that they are always welcome.
Gah. This is just frustrating. The same mistakes are made over and over and over again. And we are the ones who get to pick up the bugs. What was wrong with the way Vincent did it?
Well for one thing: Direct them to me or https://bugzilla.redhat.com. I have no problem with that and I stand for what I do. Maybe just maybe try to see the packager/distro side of things and you will see that what Vincent did was great work and is for certain things but for what is modern packaging and very distribution specific to fedora or even fedora extras the way I did it is the way to go... not by my opinion but the opinion and rules of the fedora community... if you don't like it fine... ignore it, ignore me... but I'd rather work together with you and the wine team on improving the wine experience for users and not fighting here wasting time that could be better spent improving the user situation.
- Andreas
Well I found it frustrating the way it is packaged. I just deleted all the FC5 wine stuff and downloaded it from winehq. It is a shame you don't get the all the things you need without having to install 10 packages.
My $.02, Steve Clark
On 6/13/06, Andreas Bierfert andreas.bierfert@lowlatency.de wrote:
Hm maybe it is... but then I am no wine crack... splitting stuff up is something you do in packaging and what really is encouraged by distributions. Splitting stuff makes users happy and I can see why... ;)
First off, thank you very much for building the FC packages. It was something we were sorely lacking for months and it's a thankless job. So, thanks.
I'd disagree about the 'splitting stuff makes users happy'. As a long time RH user and former sys admin, I hate it. It's one of the reasons I used to dislike Debian, although apt is very good at hiding dependencies. The last thing I want to do when I go to download a piece of software is to figure out which of the 50 million packages I need. In the end I usually download them all and try to install them. It's frustrating.
As others mentioned, the tools package really needs to be included. I understand why you split the other stuff out, so maybe we need to do something like this:
1. Put wine and wine-tools together. Call it 'wine' 2. Not include wine-nas or wine-jack. Aren't they both currently broken? For that matter, I think I heard wine-arts is as well. 3. Combine wine-debuginfo with wine-devel and call it wine-devel. They're both necessary for development, right?
The rest of the packages won't be necessary for 99% of users. Can we just tell them that in the description of the RPM? For example, for wine-cms:
"This package contains special color management for use with Wine by integrating with LittleCMS. Most users will never need to even think of downloading this package. If you're doing high-end graphics work using a commercial Windows package, you might want to consider using it."
Maybe you already do, I didn't download them and look. So, perhaps the package names should even reflect that. Instead of "wine-ldap", call it "wine-extras-ldap". That'd probably be enough for me to figure out what I needed.
By the way, the whole Gecko integration Jacek is doing seems like something packagers should tackle with Wine. It'd be nice if someone could come up with a contained Windows Gecko package that could be included with the basic Wine package.
-Brian
On 6/13/06, Brian Vincent brian.vincent@gmail.com wrote:
- Put wine and wine-tools together. Call it 'wine'
Or make wine require wine-tools. There's nothing wrong with splitting up packages, but any recommended combinations should be linked by requires until rpm/yum starts supporting tags like 'Enhances' and 'Suggests'.
- Combine wine-debuginfo with wine-devel and call it wine-devel.
They're both necessary for development, right?
Debuginfo is built automatically by rpmbuild and can't joined to the devel package. The debuginfo package is only needed for debugging, whereas (I think) the -devel package is used for things like making winelib apps. All packages in Fedora are like that, and developers are used to that now.
I think that most users would just install 'wine' and use it. I don't think it's common for people to get confused over which of all the packages they should install. Unless they know already that they need something non-standard, anything not required by the base package is probably something they won't need.
n0dalus.
On 6/13/06, n0dalus n0dalus+wine@gmail.com wrote:
I think that most users would just install 'wine' and use it. I don't think it's common for people to get confused over which of all the packages they should install.
Yeah, it is confusing.
Just a quick example. Let's say I want to install Samba. I've used Samba a lot, it's saved my butt more times than I can count. However, the packaging is a complete disaster and even as a knowledgable user I have no clue what's going on. Looking at rpmfind.net I see Samba has the following packages available:
samba (Um, I guess I'd need that.) samba-client (Well, that can be useful..) samba-server (Uh.. wait.. why isn't that part of Samba. That's what I need.) samba-common (Whoa.. if it's so important, why isn't it part of samba?) samba-winbind (Well, I may or may not need that, but it's small so I better download it.) samba-vfs (Um.. I know what Samba is, I know what vfs is. Do I need it? No clue. Better download it.) samba-pdb (No clue what this is. Maybe I won't download it. But what does it do? Anything important?) samba-python (Gee.. I like python. Maybe I should download it.)
And that's just the tip of the iceberg (samba-console? samba-vscan? samba-vfs-fake_perms?)
Anyway, it's such a god awful mess that someone deserves to be taken into a backroom and have all knowledge of building RPM's erased from their head. That's exactly what Wine shouldn't become. But who knows, maybe that's good for sys admins who keep up to date with the latest minor versions of every piece of software out there. Wine is an end-user utility who's installation and usage instructions should be:
Install Wine package -> Run program with Wine -> Magic happens -> Use program.
-Brian
On 6/14/06, Brian Vincent brian.vincent@gmail.com wrote:
Just a quick example. Let's say I want to install Samba. I've used Samba a lot, it's saved my butt more times than I can count. However, the packaging is a complete disaster and even as a knowledgable user I have no clue what's going on. Looking at rpmfind.net I see Samba has the following packages available:
I am guessing that the list you got were rpms from various different distros, each with their own naming conventions. So there's going to be a lot of overlap.
samba (Um, I guess I'd need that.) samba-client (Well, that can be useful..) samba-server (Uh.. wait.. why isn't that part of Samba. That's what I need.) samba-common (Whoa.. if it's so important, why isn't it part of samba?) samba-winbind (Well, I may or may not need that, but it's small so I better download it.) samba-vfs (Um.. I know what Samba is, I know what vfs is. Do I need it? No clue. Better download it.) samba-pdb (No clue what this is. Maybe I won't download it. But what does it do? Anything important?) samba-python (Gee.. I like python. Maybe I should download it.)
And that's just the tip of the iceberg (samba-console? samba-vscan? samba-vfs-fake_perms?)
Taking a _single_ distro, like Fedora Core 5, this is what we see: samba (just the server) samba-client (just the client, for people who don't need the server) samba-common (files shared by both, -common packages shouldn't concern anyone since they get pulled in by whatever packages are chosen)
It's simple; it allows people to save space by not having everything and it allows updates to individual parts so you don't need to download the whole lot when something changes.
Anyway, it's such a god awful mess that someone deserves to be taken into a backroom and have all knowledge of building RPM's erased from their head.
I think that person should really be you :). Your preconceptions about how things should be packaged is a bit outdated.
A few years ago there used to be monolithic packages well over 100MB that every time something small was changed the whole lot needed to be updated. Splitting up packages is a good thing. It means less install size, less bandwidth used and easier updates. The packages should have meaningful descriptions, and should depend on each other in a way that means you just choose what you want and the package manager will get what you need. Some time in the future (or already) the package manager may make the distinction between required packages, suggested packages and enhancement packages, making it easier for users like yourself to work out what they want.
n0dalus.
n0dalus wrote:
I think that person should really be you :). Your preconceptions about how things should be packaged is a bit outdated.
A few years ago there used to be monolithic packages well over 100MB that every time something small was changed the whole lot needed to be updated. Splitting up packages is a good thing. It means less install size, less bandwidth used and easier updates. The packages should have
Dream on! As long as all those subpackages are generated from the same SRPM you will save nothing and get all of them if the SRPM changes. Could be seen very nicely with X where a stoneage small program had a security bug and the _whole_ X was upgraded including the font files. And yes, X was already split in subpackages. Now that's fixed with the modular xorg but that's *not* an achievement of the packagers but of the upstream project. Where subpackes help is to limit the amount of requirements the program has. That's highly used on heavy customized servers and less so on the desktop.
I like how it's done for git in fedora extras: git is a meta package which requires all subpackages making it very easy and intuitive to get it. So having something like wine being the meta package and the actual wine subpackage being renamed to wine-core would give the user friendliness and choice for those who need it.
meaningful descriptions, and should depend on each other in a way that means you just choose what you want and the package manager will get what you need. Some time in the future (or already) the package manager may make the distinction between required packages, suggested packages and enhancement packages, making it easier for users like yourself to work out what they want.
I like how it's done for git in fedora extras: git is a meta package which requires all subpackages making it very easy and intuitive to get it. So having something like wine being the meta package and the actual wine subpackage being renamed to wine-core would give the user friendliness and choice for those who need it.
bye michael
On 6/14/06, Michael Stefaniuc mstefani@redhat.com wrote:
Dream on! As long as all those subpackages are generated from the same SRPM you will save nothing and get all of them if the SRPM changes.
I suppose you are right, at least at the moment. Hopefully one day if the build system detects that a subpackage hasn't changed then it would not update that particular rpm.
Where subpackes help is to limit the amount of requirements the program has. That's highly used on heavy customized servers and less so on the desktop.
I like how it's done for git in fedora extras: git is a meta package which requires all subpackages making it very easy and intuitive to get it. So having something like wine being the meta package and the actual wine subpackage being renamed to wine-core would give the user friendliness and choice for those who need it.
Sounds like a good idea.
n0dalus.
On Tue, 13 Jun 2006 21:29:00 +0200 Michael Stefaniuc mstefani@redhat.com wrote:
I like how it's done for git in fedora extras: git is a meta package which requires all subpackages making it very easy and intuitive to get it. So having something like wine being the meta package and the actual wine subpackage being renamed to wine-core would give the user friendliness and choice for those who need it.
Yes, meta packages are great, but seems I am one of only few people at FE who have that opinion. If you take a look at some of my other pages you can find koffice-suite (which installs all of koffice) or sylpheed-claws-plugins (which installs all plugins for sylpheed-claws).
What I can offer would be this: add a meta package wine-suite which will install all wine packages and change the summary of wine so it: a) points to the wine-* subpackages so everyone knows they exist b) tell them that there is the wine-suite meta package
and of course as discussed before add a Require for wine-tools to wine.
I hope that this is a solution the wine folks can live with. Remember: I do the packaging I do in my free time and touching wine and fitting it into Fedora Extras and upgrading it every two weeks is not the easiest thing to do and if you don't acknowledge it fine... but it rather work together with you in a friendly manner to improve things... not to make them worse ... and listening to what I have to say as someone who does a lot of packaging and knows his way around would not hurt you, would it? I do listen to your requests and if you take a look around there are not many packagers who actually do this...
- Andreas
On Wednesday 14 June 2006 12:37, Andreas Bierfert wrote:
do and if you don't acknowledge it fine... but it rather work together with you in a friendly manner to improve things... not to make them worse ...
We acknowledge that you do a great job, please don't be deterred by the harsh tone. Wine has a lot to gain from good quality packages in Fedora and conversely suffers dearly from problems caused by less than optimal packages. This may explain the vehement reactions you get.
As you will know from your experience with other projects, developers like to tell it like (they think) it is, even at the cost of sounding unfriendly.
-Hans
On Wed, 14 Jun 2006 12:37:21 +0200, Andreas Bierfert wrote:
What I can offer would be this: add a meta package wine-suite which will install all wine packages and change the summary of wine so it: a) points to the wine-* subpackages so everyone knows they exist b) tell them that there is the wine-suite meta package
Well, that would be an improvement but people tend to just guess at what they need to type for programs like yum/apt. It's one of the problems they have. Does "yum install epiphany" install a web browser or a card game? You don't know unless you check beforehand (or try it).
I think a meta package called "wine" that installed everything would be much better because that would do what end users would intuitively expect. And Wine isn't really a suite. It's a large, monolithic program. If it was a suite we'd realease separate tarballs upstream.
and of course as discussed before add a Require for wine-tools to wine.
Yes that would fix this problem for now.
I do listen to your requests and if you take a look around there are not many packagers who actually do this...
I know, and apologise for my harsh tone earlier. I think it's great you are here on wine-devel and working through the problems with us.
Hopefully you also understand the source of our frustration - I have wasted *many* hours debugging problems that turned out to be caused by bad packaging. This problem occurs all the time and when we eventually get one problem fixed, some other distro somewhere else gets it wrong again and we are back to square one. It feels like we never move forward on this issue.
Also I'm afraid the answer of "report bugs to bugzilla.redhat.com" is not OK because it is not under our control. I'd say the vast majority of end users don't use distributor bug systems and never have, not even for Debian which has always had this policy. They post to wine-users, or IRC, or our bugzilla, or random web forums. And then we get to pick up the pieces.
Maybe this summer I can work on what I always said I would and do a Wine autopackage ...
thanks -mike
On Wed, 14 Jun 2006 13:36:03 +0100 Mike Hearn mike@plan99.net wrote:
Well, that would be an improvement but people tend to just guess at what they need to type for programs like yum/apt. It's one of the problems they have. Does "yum install epiphany" install a web browser or a card game? You don't know unless you check beforehand (or try it).
That probably is true for a lot of users...
I think a meta package called "wine" that installed everything would be much better because that would do what end users would intuitively expect. And Wine isn't really a suite. It's a large, monolithic program. If it was a suite we'd realease separate tarballs upstream.
I would like that a lot better but then you have the problem that people who have wine installed now (and don't want the rest) will get everything on the next upgrade... I will think about it and discuss it with some other Fedora Extras people and see what their opinion is...
I know, and apologise for my harsh tone earlier. I think it's great you are here on wine-devel and working through the problems with us.
No problem... as long as we work for the same goals I don't mind it to much ;)
Hopefully you also understand the source of our frustration - I have wasted *many* hours debugging problems that turned out to be caused by bad packaging. This problem occurs all the time and when we eventually get one problem fixed, some other distro somewhere else gets it wrong again and we are back to square one. It feels like we never move forward on this issue.
I understand that and I hope that with some changes here and there we can (at least for the fedora stuff) minimize these problems. That is one part why I value input from upstream that much...
Also I'm afraid the answer of "report bugs to bugzilla.redhat.com" is not OK because it is not under our control. I'd say the vast majority of end users don't use distributor bug systems and never have, not even for Debian which has always had this policy. They post to wine-users, or IRC, or our bugzilla, or random web forums. And then we get to pick up the pieces.
Yes, and I hope in the future when they do report stuff it really is something with wine and not with the packages behind it.
- Andreas
Friday, June 16, 2006, 1:04:52 AM, Andreas Bierfert wrote:
On Wed, 14 Jun 2006 13:36:03 +0100 Mike Hearn mike@plan99.net wrote:
I think a meta package called "wine" that installed everything would be much better because that would do what end users would intuitively expect. And Wine isn't really a suite. It's a large, monolithic program. If it was a suite we'd realease separate tarballs upstream.
I would like that a lot better but then you have the problem that people who have wine installed now (and don't want the rest) will get everything on the next upgrade... I will think about it and discuss it with some other Fedora Extras people and see what their opinion is...
The single argument that I can add here to make Wine into a monolith package is: Where have you seen windows without *. (replace * with each possible package you are trying to create). And I'm not talking about xp embedded.
It's not a matter if we like it or not. Lots of applications depend on one functionality or another. As well as developers, when they code some features in. Or ask for the debug output. Besides, all the stuff that you split is small (for anyone to be concerned with package sizes).
Vitaliy
On Tuesday 13 June 2006 16:19, Brian Vincent wrote:
"This package contains special color management for use with Wine by integrating with LittleCMS. Most users will never need to even think of downloading this package. If you're doing high-end graphics work using a commercial Windows package, you might want to consider using it."
That was true a couple of years ago maybe, we now live in the age of digital cameras. I've seen it being used by a simple photoalbum app.
Secondly, this dll is shipped since Window 98, so many apps that use it don't check for it's presence, which results in, well, needless pain.
Lastly, this dll is just over 100k stripped, wldap32 is 280k. Given the risks mentioned above, is it really worth it to save such amounts of disk space?
-Hans
There seems to be another issue here ... you removed the rpath code with a link to two bugs that don't seem to indicate that was causing the problem.
Now I appreciate that given RPMs are not relocatable it makes no difference to your users but I am concerned that a problem apparently unconnected to it caused this change. Vendor patches are bad, for Wine they usually either mask upstream bugs or cause them.
Specifically the libGL problem is a bug in that users setup (maybe in Fedora), and I don't think it's in Wine. I don't see where the /usr/lib/nvidia search path is coming from - if it's LD_LIBRARY_PATH then we should be using DT_RUNPATH in Wine and not DT_RPATH so we should fix it. If it's in the linker config then you are relying on a very particular combination of factors which may be true for some binaries shipped with Fedora but are not guaranteed by the ELF or Linux ABIs - you can't have a /usr/lib/libGL.so.1 and always expect it to lose to /usr/lib/nvidia/libGL.so.1!
thanks -mike
On Mon, 12 Jun 2006 15:41:16 +0100 Mike Hearn mike@plan99.net wrote:
There seems to be another issue here ... you removed the rpath code with a link to two bugs that don't seem to indicate that was causing the problem.
Now I appreciate that given RPMs are not relocatable it makes no difference to your users but I am concerned that a problem apparently unconnected to it caused this change. Vendor patches are bad, for Wine they usually either mask upstream bugs or cause them.
Well, for Fedora rpath are considered bad and as wine does not allow for --disable-rpath (which I would rather use) I applied this patch to get rid of them (and solve the problems that they where causing.
Maybe fedora is broken in a way here or maybe it is not but rpath need to go out for the Fedora Extras rpm and if this fixes some bugs which are only there on fedora and the fedora rpms I am glad to close the according bugs (and leave a not the changelog so I remember what I did).
- Andreas
-
Andreas Bierfert -
Brian Vincent -
Hans Leidekker -
Marcus Meissner -
Michael Stefaniuc -
Mike Hearn -
n0dalus -
Stephen Clark -
Vitaliy Margolen