Hi, when trying to emerge ghostscript gimp-print is emerged as a dependancy, but i don't need gimp-print. I only need ghostscript with cups support (i use hpijs). A solution might be to seperate cups and gimp-print support in the ebuild, perhaps a gimp-print useflag.
*** Bug 21248 has been marked as a duplicate of this bug. ***
As Thomas said, ghostscript shouldn't automatically require gimp-print if cups support is enabled. It seems to me that the gimp-print should be enabled, and added to DEPEND if cups and X are in the USE. IMO, this is a bug, not an enhancement.
Shouldn't someone set this ebuild back to ~X86 quickly? It's silly that it wants me to install gimp so that it can install gimp-print. Most users won't know what of the installed stuff can be uninstalled once this problem is fixed. Look at all it wants me to install: Calculating world dependencies ...done! [ebuild N ] dev-perl/Text-Balanced-1.95 [ebuild N ] dev-perl/Parse-RecDescent-1.94 [ebuild N ] dev-perl/XML-Writer-0.4-r2 [ebuild N ] media-sound/esound-0.2.29 [ebuild N ] gnome-base/ORBit-0.5.17 [ebuild N ] gnome-base/gnome-libs-1.4.2 [ebuild N ] media-libs/gdk-pixbuf-0.21.0 [ebuild N ] dev-perl/XML-Parser-2.31-r1 [ebuild N ] dev-perl/gtk-perl-0.7008-r9 [ebuild N ] dev-perl/File-Spec-0.82 [ebuild N ] dev-perl/Test-Harness-2.28 [ebuild N ] dev-perl/Data-Dumper-2.101 [ebuild N ] dev-perl/Inline-0.44 [ebuild N ] dev-perl/Filter-1.29 [ebuild N ] dev-perl/ExtUtils-F77-1.14-r1 [ebuild N ] dev-perl/PDL-2.3.4 [ebuild N ] media-libs/mpeg-lib-1.3.1-r1 [ebuild N ] media-gfx/gimp-1.2.3-r3 [ebuild N ] net-ftp/curl-7.10.2 [ebuild N ] net-print/foomatic-2.0.0 [ebuild N ] media-gfx/gimp-print-4.2.5 [ebuild U ] app-text/ghostscript-7.05.6-r2 [7.05.5-r2]
It seems to be a problem with this line: cups? ( || ( gimp-print gimp-print-cups ) ) I understand what it is supposed to do, but is it really possible to do it this way? If it is not, portage doesn't like it that much. Perhaps, there is another way to solve this problem?
this ghostscript "update" would merge xfree even on (server) machines, where USE="-X"! this gimp-print dependancy is really unnecessary. it now prevents me from running "emerge -u world" :((
What is the reason behind the dependency on gimp-print? If we trigger on cups we should depend on gimp-print-cups, NOT gimp-print. The best thing to do would be testing if either one is installed and if not then it should install gimp-print-cups. The problem with the current use line is that it ALWAYS want to install gimp-print. That will fail because of gimp-print-cups that is already installed on the system (in my case). Personaly, I don't quite like ghostscript depending upon gimp-print*. Is this really necessary? And could we get a little response from some developer please! This is actually a very annoying and major bug. I don't understand how this could get through testing. There must be quite a few people out there experiencing this problem.
Created attachment 13464 [details] New ebuild recognizing gimp-print correctly
I have made an altered version of ghostscript 7.05.6-r2.ebuild that seems to recognize gimp-print just fine. Not too sure, please test anyone. Not that good at writing bash. If there is some developer reading this, could you please look at my ebuild so we can, hopefully, put an end to this.
Regarding your change: if use cups; then has_version gimp-print-cups || has_version gimp-print \ && myconf="${myconf} --enable-cups --with-gimp-print" else myconf="${myconf} --disable-cups --without-gimp-print" fi I think that if someone has USE=cups and neither gimp-print nor gimp-print-cups installed, this does the wrong thing. Apart from this issue, en ebuild that behaves differently depending on external factors is probably a big source of trouble for the developers, so I reccomend to find a different solution. As anyone tried just switching gimp-print with gimp-print-cups in DEPEND? Otherwise I would opt for a virtual/gimp-print or even for a gimp-print use-flag.
Yes, I agree with you. My solution is not a good idea actually. What if we always require gimp-print-cups? Just switching the gimp-print and gimp-print-cups, as you say Guidi, would do. Is that a solution good enough? I think a useflag is a bit of an overkill if we can solve it the way described above.
No, it's not that easy. :-( You can't just switch the the two words. (Look at comment #6) I question if that construct is correct. Could be a bug in the current Portage version I'm using, though.
I vote for a virtual package because we have two packages that can't be installed at the same time. Funny, couldn't they be made to complement each other? I don't know what to think about the USE flag issue.
hmm... afaik someone did an ebuild which kinda combines gimp-print and gimp-print-cups(which is only the devel version of gimp-print) i'll check it out ..
In idea came to mind looking at the latest attachment to bug #14909. Does the latest portage version support local USE flags? If it does, it could be a good idea to let a local USE flag control whether gimp-print should enable support for gimp or not. Then we could delete gimp-print-cups for good! OK, it looks like gimp-print ebuild needs some tweaking in the install section also. Any thoughts?
will be seperated in next ghostscript version.
ghostscript-7.05.6-r3 now in portage ...
Any good response to the third release? I would like this to be put to stable as soon as possible because this bug is a MAJOR hindrance in my system upgrades. I'm getting desperate... :-)
I agree. What's the hold up in marking it stable?
Thank you, my printing now works like a charm!
