Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

xsane is a gtk program. Why is it pulled in by net-print/hplip when USE="qt3"
or USE="qt4" is enabled? It should be pulled in by the gtk or X use flag.
change

                scanner? (
                        dev-python/imaging
                        qt3? ( >=media-gfx/xsane-0.89 )
                        qt4? ( >=media-gfx/xsane-0.89 )
                        !qt3? ( !qt4? ( >=media-gfx/sane-frontends-1.0.9 ) )

to

                scanner? (
                        dev-python/imaging
                        gtk? ( >=media-gfx/xsane-0.89 )
                        !gtk? ( >=media-gfx/sane-frontends-1.0.9 )

Reproducible: Always

The qt3 and qt4 USE flag indicate that you have a choice between qt3 and qt4
for the graphical interface, not that you want to use the qt3 or qt4 libraries,
although the latter is implied. When enabling the graphical interface (either
qt3 or qt4 USE flag) and the scanner then you need xsane. The fact that xsane
depends on gtk has nothing to do with this.

If you don't want xsane then just disable the scanner USE flag. And if you want
the scanner but no graphical interface then disable both qt3 and qt4 USE flags.

I could add a gtk USE flag for next version if that's what you're asking. But
the logic you propose wouldn't work.

Denis.

(In reply to comment #1)
> the logic you propose wouldn't work.

On second thought it all depends on what we want. Let me think about it.

Denis.

It's just that the use flags qt3 and qt4 pull in a gtk+ related dependency
(xsane). They also pull in qt related dependencies, of course, but a qt* use
flag should not pull in any gtk stuff. qt/KDE users should be able to have qt3
and qt4 enabled without gtk+ being pulled in by these flags. I as a GNOME user
want gtk+ stuff to be pulled in through a gtk use flag, without any qt stuff.
in short: pulling in a gtk+ program through a qt* use flag is contradictory.

(In reply to comment #3)
> They also pull in qt related dependencies, of course, but a qt* use
> flag should not pull in any gtk stuff.

Sorry, we have no such rule. You're extrapolating the role of USE flags. USE
flags are for selecting features [1], and possible dependencies are a only
consequence of features. When an optional feature, triggered by the qt3 or qt4
USE flags, requires qt along with another package which itself depends on gtk+,
well, guess what... gtk+ will be pulled in.

The situation until not so long ago was that you'd have to enable the X USE
flag to get the graphical interface, and that would indirectly pull in both qt3
for PyQt and gtk+ for xsane (if you also had scanner enabled). This is an
example of how USE flags and dependencies do not always strictly coincide.

Recently upstream started adding code to allow the use of qt4 instead of qt3.
Note that this is not documented yet and thus experimental. So I added the qt3
and qt4 USE flags to let users choose which one they wanted. I also removed the
X USE flag because it was ridiculous to have X, qt3 and qt4 when the latter two
were sufficient. But the ebuild still indirectly and optionally pulls in X
dependencies as you can imagine. This is another example of how USE flags and
dependencies do not always strictly coincide.

Part of being a developer is about making sensible choices in order to make
things usable. And we usually do so considering the general interest, meaning
we can't always satisfy everybody. Also, Gentoo is probably the most
configurable distribution but it's not always a good idea to leave everything
configurable.

Denis.

[1]
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=2#doc_chap1

Well I guess, you know what you are doing. It just seems strange to me, to have
a gtk programm pulled in by qt flags rather than through the gtk flag. Does
hplip require qt to work with xsane? I see that hplip offers a qt gui that can
of course be enabled through a qt use flag, but afaik it has nothing to do with
xsane. What I see is a _qt_ flag pulling in a program that has nothing to do
with _qt_. I always thought the qt use flags should be enabled by qt users to
enable qt support and nothing else.

(In reply to comment #5)
> It just seems strange to me, to have
> a gtk programm pulled in by qt flags rather than through the gtk flag.

I understand what you mean. Don't worry though, you're not the only one
confused by this. To make it simpler just think of USE flags as features and
dependencies as collateral damage. And as we all know it, collateral damage is
rarely well controlled.

In our particular situation it's not hplip which pulls in gtk+, but xsane. And
hplip isn't in control of xsane dependencies. Both upstreams made different
design decisions. If someday xsane decides to go to wxWidget or even Qt, or if
hplip switches from PyQt to PyGTK, they won't ask for each other's
authorization before doing so. But as long as you want to have a graphical
interface and scanner features you have to live with the sum of hplip and xsane
dependencies. It's unfortunate that in this case it means both Qt and GTK+.

> I see that hplip offers a qt gui that can
> of course be enabled through a qt use flag, but afaik it has nothing to do
> with xsane.

Yes, it has to do with xsane. The Qt GUI opens xsane when you click on "Scan"
in the "Actions" tab.

> I always thought the qt use flags should be enabled by qt users to
> enable qt support and nothing else.

The issue is in the "and nothing else". Remove it and you're good, especially
when dealing with indirect dependencies.

Denis.

Ok, I understand it mostly now, thanks for your explanations. And sorry for
this bugreport, I guess it can be marked invalid.

Let's keep it open. I'll see if I can do something about this.

Denis.

Done in 2.8.7. Thanks.

Denis.