Bugzilla Bug 19937

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 an attachment (id=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!