Hi, I'm currently trying to get rid of strictly gnome-related packages which aren't hardly needed. After removing esound (which needed changes to libgnome and libgnomeui packages, see bug #72147), I tried to remove gnome-icon-theme (and hicolor-icon-theme) and inject them to bypass the dependencies. It worked fine, because using gtk-qt-engine the icons used are the one selected by KDE (in my case crystalsvg). Unfortunately, libgnomeprintui seems to have a build-time dependency on gnome-icon-theme, which can't be bypassed by a configure option. I don't think this is needed, anyway, like the comment in configure.in says: dnl It is ugly to put a build time check in for a run time dependency on gnome-icon-theme dnl but this will hopefully keep the packagers on their toes I removed gnome-icon-theme dependency editing the configure scripts and it builds an run without glitches. I'm attaching the patch I used to edit the configure scripts and a patch to the ebuild which removes the dependency on gnome-icon-theme and applies the patch. HTH Regards, Diego
Created attachment 44979 [details, diff] libgnomeprintui sources patch
Created attachment 44980 [details, diff] ebuild patch
It's great, that you step in Diego. You're not the only one, who is annoyed by these dependencies.
*** Bug 72147 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 6920 ***
oh dear, sorry for the spam mail
I talked this over with obz and here is the conclusion on this bug. It is correct that libgnomeprintui should not require gnome-icon-theme, and I added a patch so it doesn't. However, a default icon theme should be required in order to avoid some ugliness. I have added hicolor-icon-theme as a replacement for gnome-icon-theme. It does the job and weighs in at a much smaller 30k. According to the freedesktop standards, there should always exist a hicolor theme. I don't know if kde still includes its own hicolor theme(if it does it shouldn't), but everything should move to the fdo standard package soon enough.
hicolor theme is just a set of paths currently, gnome-icon-theme is needed for libgnomeprintui to function properly. The comment in the configure script points to the fact that runtime deps do not really belong in configure scripts afaics. As long as there is no other theme that can function as stock theme, gnome-icon-theme is needed, the dep should not have been removed. qt-gtk engine is too much of a hackish cornercase to take into account.
>qt-gtk engine is too much of a hackish cornercase to take into account. Come on, you may not like it, but it runs fine for me and others since months.
I do not doubt it works to some extent, but it's neglectable to the ppl using a 'normal' theme engine & as such not worth making incorrect hacks for. I'm not sure how it is implemented (*sgh* i know, gotta look it up now), but the only proper way would be to have kde & gnome follow a common spec. I'm not sure where this process is atm, but that would be the only proper solution here. In that case you would still have a dep on some icon theme in libgnomeprintui, that wouldn't change.
As far as I can see, if I haven't the gnome's icon it simply fails to show the icons. And then? I don't need them at all, why should I be forced to install them if I don't care to have them? It doesn't seems like it crashes or it's totally fscked up if I use it without the icons.
We try to deliver the software as intended, that is with icons. That it doesn't crash the apps is a non-argument, you even say yourself that the only reason you want this is because a gtk theme maps them to other icons you do have. Sure, we can deliver say whole of gnome without icon theme as well, it just looks a bit weird with all the missing icons, all in the name of 'it is not /really/ needed'.
Wine it's provided with use-flags to allow the user to remove support for some package for example cups, jack, alsa and arts. But wine itself doesn't allow to turn them off or on at request. And I think there're many different cases where something like that applies, where the requests of the users are put above the original sources. And to quote the 'About Gentoo Linux' page: "We produce Gentoo Linux, a special flavor of Linux that can be automatically optimized and customized for just about any application or need." so why can't be customized to allow not to depend on non-essential packages? By the way, the current libgnomeui forcefully install the gnome-icon-theme, and because libgnomeprintui depends on libgnomeui, removing the dependency in this package doesn't change the current behaviour. However, I think that the metapackage gnome, depending on gnome-icon-theme should be enough, but this is another story.
It is an essential package for a complete UI, which is in my opinion just as important as having all libs especially for something that is after all a set of widgets. It's just not obvious broken as missing a lib and thats why people tend to make fuzz about these things. libgnomeprintui has no dep on libgnomeui as far as i am aware.
Sorry for mistake I thought libgnomeprintui was also depending on libgnomeui. Anyway this shouldn't avoid the use of the library in any case: what about other icon themes? The Gnome's one isn't the only one, and I can change it so I don't depend on it. Maybe we should add a 'gnome' flag which adds the dependency on the icons, but still I think this is a bad way to handle it. If KDE doesn't find its icons it simply defaults to what it can find. If it finds nothing, it shows nothing.
c10: >I do not doubt it works to some extent, but it's neglectable to the ppl using a 'normal' theme engine & as such not worth making incorrect hacks for. It is a "normal" engine, which just uses Qt to draw... >I'm not sure how it is implemented (*sgh* i know, gotta look it up now), but the only proper way would be to have kde & gnome follow a common spec. I'm not sure where this process is atm, but that would be the only proper solution here. It's something that I ever wanted, long before M$ yelled out, they'll have a fancy xml-based vector-gui thingie for Longhorn - in short, something similar to Quartz. Well, I think it's due to the "XFree86 period" that never happened anyhing in this reagard, but the point is that _we_don't_have_such_a_spec_now_ and I did not hear anything yet from freedesktop.org, Gnome, Trolltech, ... that they sat together and worked on it. >In that case you would still have a dep on some icon theme in libgnomeprintui, that wouldn't change. Personally I'm not /that/ interested in the icon theme, but I had enough of it, to have my own libgnomeui ebuild w/o the gnome-themes PDEPEND. I see no reason, why it couldn't be changed to gtk-qt-engine OR gnome-themes maybe by a kde? opt-in to be on the safe side. There's also still the issue, that's not pssoble to install Gtk/Gnome stuff w/o any sound daemon (in fact esound), even though I don't have any Gtk application installed, which needs sound and don't want it. The other way around, you _can_ drop aRts, if you just want kdelibs and maybe amaroK with Gstreamer on your Gnome desktop.
Created attachment 45716 [details] libgnomeui-2.8.0.diff i can't really imagine, that this is a big issue for gnome purists
Arts is a completely different thing, please stay on topic. First, we've established that we definitely _do need_ an icon-theme for libgnomeprintui. It's not feasible to deliver a desktop with missing widget icons, I'm sorry, but people like to have icons on their desktop rather than large X's. This will not change, we _need_ an icon-theme. The question is allowing for customising the default icon-theme, so that users who prefer something other than gnome-i-t aren't locked in. We can't use a virtual for this, because it would only allow one theme to be installed. What if I want to have both gnome-i-t and qt-gtk and switch between them as I like? We can't put some ( gnome-i-t : qt-gtk ) hackery in the ebuild, because it doesn't scale past those two, and it's a solution to the wrong problem. And as mentioned in the first paragraph, we can't remove the dependency all together. When I look at it like that, and ignoring the standards proposal, I don't see a way for portage to handle this situation, where "this situation is" - "Have multiple packages installed, but only require at least one of the 'group' as a dependency". Carsten? Diego? Do either of you have a reasonable solution to this problem, taking this into account.
Carsten, you fail on point #2 > We can't put some ( gnome-i-t : qt-gtk ) hackery in the ebuild, > because it doesn't scale past those two, and it's a solution to > the wrong problem.
After talking it over with jstubbs, I have realised that it _is_ possible to have multiple packages installed for a virtual, so that may now be an option.
So what about a virtual? Or do they blocks each other away? (sorry I don't know that as good as I needed to) We can make gtk-qt provide a gnome-icons virtual like gnome-icon-theme and so on, and make libgnomeprintui depends on a virtual gnome-icons package, which can be provided by the gnome-icon-theme, by gtk-qt (using kde's owns icons), or by any other gnome icon theme found on gnome-look and then ebuilded up by some unofficial ebuilder (we are quite a lot out there I think, especially for eyecandy stuff). This will make the dependency more 'true': you still need to have icons, but you are not forced to have the defaults one. About the esound daemon, there's bug #6920 which talks about it, but I'm not finding a clean way a part from hacking the source directly to avoid the need of esound. Anyway, libgnome builds fine w/o it, disabling it. Like Carsten, I'm having my own ebuilds without these forced dependencies, and I'm living happy.
Sorry in my mailbox comment #18 never arrived, so I didn't saw the note about the virtuals. But, I tried to look better, and I found out that both sun-jdk and blackdown-jdk provides the same virtuals (if we use the same 1.4.2.xx version), and they can coexists. In fact, I used to have both installed, as many other out there. So there's a way to have a virtual which isn't an or exclusive. We just need to use the same method java jdks and jres uses, and we have this cleaned up. Still I don't think that giving a desktop environment with icons should be done by libraries themselves. To have the complete GNOME environment there's the gnome metapackage which seems to do its works well.
libgnomeprintui is basically just widgets. Widgets need icons. The dependency will stay here, because it's required here. Before we choose a virtual, we need to investigate o) what packages could provide it? (gnome-icon-theme, gtk-qt-engine, are there any others?) o) if we want all of these packages to co-exist, can they actually do so without conflicting files - ie, do they really provide a true virtual.
I think that in portage we have no other ebuilds which provides icons for Gnome's apps: most of the eyecandy stuff isn't in portage but in unofficial ebuilds (also if maybe an eyecandy-specific repository could be the joy of some eyecandy freak :) ). Actually I don't have others too, because I usually take care only of KDE stuff, but other unofficial ebuilds can have them, and providing a virtual interface we can help these to provide a better integration with the current portage. In that case, they need to ensure that there're not conflicts between their ebuild and the gnome-icon-theme one. About gtk-qt and gnome-icon-theme, I'm sure there's no conflict, so I think they can be virtualized without problems.
c18: >Arts is a completely different thing, please stay on topic. I don't speak about aRts. I speak about Esound. And I speak about my general disappointment, that the Gnome herd seems to care about the Gnome desktop exclusively and everything else is more or less falling behind. Please don't take this as a rant - it's just the perception I, as a user of your ebuilds, have. Examples? Here's the first one: >We can't put some ( gnome-i-t : qt-gtk ) hackery in the ebuild, because it doesn't scale past those two, and it's a solution to the wrong problem. Mike, your comment looks like you did not even have a look at my small patch. It doesn't even touch the gnome-icon-theme post dependency. Also the "it doesn't scale argument" is void, since there simply is not other real alternative, than the gtk-qt-engine to the general gtk/gnome engines. Gnome desktop users won't even notice a difference, due to the small dependency change. Once again, I'm aware that it takes time to changes things. The point is, that there's absolutely no interest on your side to improve things - at least you communicate it this way. Another example? Have a look at Bug 73243. Officially development documentation only gets installed on a Gentoo box, when the doc use flag is set. You're violating this. Did anyone of you approach upstream developers to improve the situation in the long run? Next example: Bug 40453 - not a new bug, as you may agree. While the attached patch will work flawlessly, I was lazy and made my own imlib ebuild with an ugly sed expression to get my box Gtk1 free, forcing me to apply the recent security patches on my own, instead feeling warm to use Gentoo and just doing `emerge imlib` fixing the issue. Last but not least Esound. Is it really a non-optional dependency? I did not investigate yet, since I assumed, that you have an open ear for all your users. Have you!?
I wish people would inform themselves before making a lot of comments. As mentioned in comment #8 the gnome icon theme provides the only stock theme available. It pretty much follows the fdo standards as far as they have developed (contrary to what #16 claims), the only problem there is that spec is incomplete and the gnome & kde implementations are different iirc. So they're not interchangeable perfectly as is, there is actually work being done on this on the fdo/gnome side of things. Plus that our KDE used to install it in one of it's own made up prefixes iirc, so in that case it still wouldn't be interchangable on Gentoo (nitpicking mode entered, much like comment #25). Bottomline, a viable solution would be to virtualize the icon-theme dep when it makes sense (not now), as said in comment #8 . Regarding pushing gtk-qt engine & it's stability. Sure it uses qt, does it use 2 concurrent mainloops (?), yugly. I looked at the code a bit & it is a ugly hack, not just the icon mapping, but also the special cases for WM's, browsers .. etc. Just a few versions ago it crashed every x minutes, sure it may have improved but I doubt you can ever label it 'stable'. As such we cannot officially support it as backend, it gives out the wrong signal to the user. Now to go -for the last time- offtopic in thus bug (please keep it on-topic next time) : comment #25 & bug #73243 . Carlo you really should know this & it's quite obvious from my comment in that bug : USE flags are optional when the upstream source makes it optional, that is not the case here. If that is intended or not is of little relevance to our current situation. Your definition of the doc USE flag or USE flags in general is incorrect. bug #6920 : we do not deny it is not possible, but noone all this time from the 'we don't need esound' camp came up with a proper patch. That was all we asked for, we are a community distro after all, we are not your code slaves & have more urgent things to do. Apperantly it wasn't that much of a problem for these ppl, at least that is my conclusion (comment #21). Your 'tomorrow' is already a good 20 days passed Diego. bug 40453 : this is actually a portage bug, there is no way to dep on USE flags. Any but the last fix proposed in that bug was just a hack. I'm not sure if I wrote it down there, it might be doable to USE flag gtk1 support now, because gnome1 is not used very much anymore. But when gtk1 was still very much in use it wouldve resulted in a dozens of bugs if we made the gtk dep optional, anyone building gnome in that time wouldve hit it.
>Plus that our KDE used to install it in one of it's own made up prefixes iirc, so in that case it still wouldn't be interchangable on Gentoo (nitpicking mode entered, much like comment #25). This issue can't really be changed right now, maybe for Qt/KDE 4. The difference is, that the kde herd is aware about it and doesn't refuse to influence the upstream development in due time. Regarding nitpicking, I don't think that I'm rude with that what I say. >Regarding pushing gtk-qt engine & it's stability. Sure it uses qt, does it use 2 concurrent mainloops (?), yugly. gtk-qt-engine-0.5 is absolutely stable and the above patch won't even invoke it by default. You have to install it explicitly. Regarding the two mainloops - yes, it has to work this way, but it's less ugly than using Gnome themes [my very personal POV ;)]. >Your definition of the doc USE flag or USE flags in general is incorrect. So it's the Gentoo way to keep the status quo!? Definitely not. And it's not my definition, but I was told, that it is one of the old unwritten policies, that user documentation always gets installed and the doc flag is for development docs, examples, etc. >we are not your code slaves & have more urgent things to do I think I did say, that I do not expect everything to happen within a time frame. I just ask you to take other interests into account. If the attitude that speaks out of your words defines our work "together" to provide a wonderful distro for everyone, then I should ask myself, why I do care for bugs I'm not personally interested in. >bug 40453 : this is actually a portage bug, there is no way to dep on USE flags. Eh? You just have to fix the configure script. That we don't have a "ebuild_x w(/o) use_flag_y?" check by portage, is true for _a_lot_of_ ebuilds and no reason not to apply it. There are a lot of more serious bugs regarding portage.
About #6920, I'm having some real-life trouble, in conjunction with many other projects I'm following, and are many days I can't take a new source tree to work at, still I haven't forgot it, as soon as I have time to breath, I'll work on it. I'm a developer myself and I know that there're time when something can't be fixed immediatly :)
I am probably the reason this has gone on longer than it should have, so I will try and sum this up properly as I should have the first time. Comment 17: I'm not sure I get the point of your patch as it still brings in gnome-icon-theme as a dep, and does nothing to address removing it(which is what the bug was about). As far as being purists go, we are just trying to provide a working set of widgets as upstream has defined them. Using gtk-qt as a dep in place of gnome-icon-theme is wrong because it doesn't fit the definition of a dependency at all. It isn't an icon theme which provides the proper icons for this package. Also, It forces the user who had installed gtk-qt theme engine to use it all the time for a proper display of widgets, since if they ever change their mind, there will be no gnome-icon-theme to fall back on. The user should never have to rely on a certain theme engine hack just to be able to properly display icons, that is ridiculous. Final point is this: Upstream gnome lists this as a dep because they want to be sure the user always has an option to see the proper icon in their widgets. We respect that and feel the same way, so we include the proper stock icon theme. Unless you can provide a situation where the user will always see the right icons no matter what theme, etc..We need to have gnome-icon-theme as a dep. Comment 27: I think it is a bit rude to accuse foser of only taking his own interests into account. I'm sure he has no interest in this bug anymore, yet has taken an obscene amount of time to explain why your solution can't work, what might be a possible solution in the future, and even to go through the source code of the package you mentioned. Both of you have attempted to take the bug off-topic and drag other arguments in. I'd say foser has spent more time then was deserved on this bug. Unless you have a solution that works in all cases, there isn't much more to add.
>I'm not sure I get the point as it still brings in gnome-icon-theme as a dep Wonderful, first you say you've no clue about it and then you lament about the stupid icon theme... The patch allows to let everyone live with gnome-themes by default, but if you explicitly emerge gtk-qt-engine, you can get rid of gnome-themes and gtk-engines. It has absolutely nothing to do with the gnome-icon-theme. It would be nice, if you could let foser speak for himself. I think he's more than able to do so and needs no speaking tube (and that was maybe a bit rude).
Actually I thought that we were came at the conclusion that using a virtual/gnome-icons package, provided both by gnome-icon-theme and gtk-qt-engine (and by third party ebuilds), will fix this up. I think this is the better way to handle this, because it requests a set of gnome icons, without need to force the user to use the defaults one. Why this is still not possible at all? Remember that if I have gtk-qt-engine installed, I still can want to not use it, without problem, and if I have both gtk-qt-engine AND gnome-icon-themes, I'm able to switch the theme and so the icons. (The only off-topic note I put in this comment is: also libgnomeui should PDEPEND on that virtual package, which requires the user to have at least one set of icons installed, but allow him to choose between different ones).
>Actually I thought that we were came at the conclusion that using a virtual/gnome-icons package, provided both by gnome-icon-theme and gtk-qt-engine (and by third party ebuilds), will fix this up. >Why this is still not possible at all? Because gtk-qt-engine doesn't provide icons. It isn't an icon set, so it can't provide virtual/gnome-icons in any way.(It might be a good choice for a gtk engine virtual, but not icon theme) It would be a good idea to have a virtual for the icon theme, when it is possible. As said in comment 8, and again in comment 26, gnome-icon-theme is the only package that provides all stock gnome icons, so there is no need for a virtual at the moment. >Remember that if I have gtk-qt-engine installed, I still can want to not use it, without >problem You do have a problem, because when not using it, you will see big red and white X's in the print widget. You mention in comment 11 that not showing the icons isn't a problem for you. While that is fine and may be true for other people as well, we aren't going to ship an incomplete package under any circumstances. >and if I have both gtk-qt-engine AND gnome-icon-themes, I'm able to switch the theme >and so the icons. This is fine and I have no problem with it. The behavior of the ebuild doesn't need to change for this. With the current ebuild you are still free to install gtk-qt engine, and then have it fall back to gnome-icon-theme when you are not using it. This is why gnome-icon-theme is the only solution at the moment: User installs gnome-icon-theme, it places stock icons in the hicolor folder theme/application always checks hicolor, and always displays icons. Your solution of having gtk-qt engine be a replacement for gnome-icon-theme doesn't work this way. It only works under a specific situation where the user decides to run gtk-qt engine. User installs gtk-qt engine instead of gnome-icon-theme. They user gtk-qt engine, everything looks fine, widgets mesh and there is harmony. One day they decide to not use it, so they stop running it. No stock gnome print icons in failsafe hicolor theme. Now they are missing icons in some of their gnome widgets, and it looks ugly. User wonders why this happens. Because we failed to provide a complete dependency. Diego: I respect your concern for portage trying to install unneeded deps, but until there is a package that works under _any_ situation as gnome-icon-theme does, there is no other solution. I would be happy to discuss it more via irc or any other method that isn't bugzilla, as this bug has lived beyond its usefulness.
At least can you add the virtual/gnome-icons package anyway? This will help unofficial ebuilders like me when creating ebuilds for icon themes. I were told that portage isn't a place for eyecandy stuff, and there are many other contributors which doesn't submit the ebuilds, but still make them. If you add the virtual/gnome-icons package, giving the PROVIDE to gnome-icon-themes, then other ebuilders can give it, and then users which installs the eyecandy ebuilds can install a replacing package.
*** Bug 104970 has been marked as a duplicate of this bug. ***
*** Bug 104969 has been marked as a duplicate of this bug. ***
