gdk-pixbuf works just fine without gnome, but the ebuild enforces inclusion of gnome. I would suggest a gdk-pixbuf-gnome and a gdk-pixbuf (no gnome support) ebuild.
this has come up so many times, it is not even funny any more. Daniel, we might want to give this some serious consideration.
Only way to properly fix this, is to have the ability to specify the USE flags something should have been compiled with in DEPEND. Otherwise we will have half backed hacks which will only make things worse.
*** Bug 8401 has been marked as a duplicate of this bug. ***
Any news on this front ?
another package we need this feature for is vim (because vimpart needs a vim merged with dcop enabled (kde in use)) would be nice to have this soon in portage, than we can merge [g,k]vim[-core] ebuilds back into one ebuild.
Another "case": dev-ml/lablgl depends on dev-lang/ocaml and gtk. Ocaml has gtk as an *optional* dependency. Right now I can only do a dirty hack in ebuild which will only catch ~90% of situations (namely check if gtk is defined system-wide and if not check if ocaml is already installed). This is better than nothing, but still bad and ugly. So yes, having this feature will be very nice. George
Could this be resolved some time soon ? If you need help, just tell us how.
*** Bug 7554 has been marked as a duplicate of this bug. ***
has this been fixed in emerge now? I do ask because it isn't yet mentioned neither here nor in othe other (duplicated) bug report. otherwise, when will this be fixed? at which position is this on the portage todo-list?..... many thanks, Christian Parpart.
portage can do this now
actually, it still cant
*** Bug 34905 has been marked as a duplicate of this bug. ***
*** Bug 38907 has been marked as a duplicate of this bug. ***
Created attachment 24275 [details, diff] have_flags.patch I don't really know what should be the behavior of a dependency on USE flags, but at least here is a patch that adds a new portageq/ebuild.sh function to test if a given pkg has been emerged with some given use flags. Usage from portageq is: % portageq have_flags <root> <depend_atom> [<use_flag>]+ ==> exit with code 0 if all matching pkgs have been compiled with all the required flags. Here "all pkgs" means that if there is no matching pkg, it will also exit(0). (Use has_version if you want to ensure there is at least one matching pkg, but this is not the goal of this function.) Usage from an ebuild: have_flags <depend_atom> [<use_flags>] ==> returns 0 or 1, with the same behavior as the portageq call. I think the good way to use it would be in pkg_setup(), to display an error and die if the user have to reemerge some pkg with different use flags. For instance: pkg_setup() { have_flags "=dev-ml/lablgtk-2*" glade \ || { eerror "Please reemerge dev-ml/lablgtk-2.x with the \"glade\" local USE flag enabled." die "You need to reemerge something." ; } }
*** Bug 41170 has been marked as a duplicate of this bug. ***
*** Bug 41452 has been marked as a duplicate of this bug. ***
*** Bug 57828 has been marked as a duplicate of this bug. ***
Let me add my voice to really wanting this in portage. Many of the various mono packages rely on the gtk-sharp package having certain USE flags enabled to build the different optional pieces (like gnome-sharp and gtkhtml-sharp in particular). It would be wonderful not to have to add silly checks for files all over the place instead of having USE based DEPENDs. On IRC i've heard conflicting "this'll be in .51" to "i've seen no code for this yet"... so what's the status?
*** Bug 53467 has been marked as a duplicate of this bug. ***
*** Bug 20326 has been marked as a duplicate of this bug. ***
I guess I didn't do that properly.. :/
Just had an email 'round gentoo-dev about this: my use case is that I need to test if gcc was compiled such that the Java language module is present, ie USE=gcj resulting in `gcj` being available on the system. So, +1 or whatever :) AfC
/me hates duplicate mails. Not a chance this will be in the 2.0.51 series, but should be in what comes after.
Comment on attachment 24275 [details, diff] have_flags.patch Marking this patch obsolete since a similar hack has been included in eutils.eclass.
*** Bug 74328 has been marked as a duplicate of this bug. ***
So what is the recommended way of handling this situation? ---snip--- # [FIXME] wxpython must be installed with USE="unicode" # [FIXME] tunepimp must be installed with USE="python" RDEPEND=" >=dev-python/wxpython-2.5.1.5 dev-python/python-musicbrainz >=media-libs/tunepimp-0.4.0_pre1 " ---snip---
the current work around is to use the function 'built_with_use' in the eutils eclass
*** Bug 81461 has been marked as a duplicate of this bug. ***
*** Bug 83554 has been marked as a duplicate of this bug. ***
*** Bug 106685 has been marked as a duplicate of this bug. ***
*** Bug 51584 has been marked as a duplicate of this bug. ***
*** Bug 111031 has been marked as a duplicate of this bug. ***
*** Bug 113599 has been marked as a duplicate of this bug. ***
just wanted to let add a +1, avahi with howl-compat use flag and gnome-vfs don't play well, because avahi blocks howl and gnome-vfs is hard coded to howl, not some virtual that only gets set to avahi when you emerge it with that flag. anyways i'm sure i'm way of base here, but it is kind of annoying, seeing as the newest banshee requires avahi
*** Bug 128123 has been marked as a duplicate of this bug. ***
*** Bug 133058 has been marked as a duplicate of this bug. ***
*** Bug 136448 has been marked as a duplicate of this bug. ***
*** Bug 136578 has been marked as a duplicate of this bug. ***
*** Bug 142209 has been marked as a duplicate of this bug. ***
A while ago I installed media-video/VLC. Emerge told me that I also need to install wxGTK and a few other packages. When it came to install VLC, VLC complained about wxGTK, because it was built without the "unicode" USE-Flag. So I had to reemerge wxGTK. This took me a long time - only 1100MHz... I would be glad about a portage, that could tell me, before I start emerging anything, which USE-Flags are missing.
*** Bug 149423 has been marked as a duplicate of this bug. ***
*** Bug 149556 has been marked as a duplicate of this bug. ***
*** Bug 152930 has been marked as a duplicate of this bug. ***
*** Bug 153366 has been marked as a duplicate of this bug. ***
*** Bug 155945 has been marked as a duplicate of this bug. ***
Why is "built_with_use" only a work around and not the solution, as stated by SpanKY/vapier in comment #27 ?
Because built_with_use happens after dependency calculations. It's only useful for make the install stop with an error. You want is to be able to express the dependency in *DEPENDS so that portage can pick the right packages to install in the first place.
*** Bug 175444 has been marked as a duplicate of this bug. ***
Any news here? Has calculation of USE-flags in dependencies been considered for EAPI-1 proposals?
*** Bug 189966 has been marked as a duplicate of this bug. ***
*** Bug 190855 has been marked as a duplicate of this bug. ***
*** Bug 191370 has been marked as a duplicate of this bug. ***
*** Bug 193335 has been marked as a duplicate of this bug. ***
*** Bug 197666 has been marked as a duplicate of this bug. ***
*** Bug 198126 has been marked as a duplicate of this bug. ***
*** Bug 199460 has been marked as a duplicate of this bug. ***
*** Bug 206613 has been marked as a duplicate of this bug. ***
*** Bug 208872 has been marked as a duplicate of this bug. ***
Happy 6th birthday, bug 2272! (yes, I'm being an unconstructive asshole ;) )
(In reply to comment #59) > Happy 6th birthday, bug 2272! (yes, I'm being an unconstructive asshole ;) ) Yup. Luckily we also have constructive non-assholes. [23:57] +CIA-9 zmedico * gentoo/xml/htdocs/proj/en/portage/index.xml: Note that USE dep support is in svn r10387.
Fixed in or before 2.2_pre8
Brilliant, thanks :) Somewhat off-topic - does anyone happen to know if this works in paludis, too?
Here are some examples showing everything that's supported when using >=sys-apps/portage-2.2_pre4 with EAPI="2_pre0" set in the ebuild (bug #233213 tracks EAPI 2_pre0). These come from "Ebuild" chapter of the html docs that are installed with portage when USE="doc" is enabled. Unconditional USE Dependencies Table 6.2. Syntax Examples Example Meaning foo[bar] foo must have bar enabled foo[bar,baz] foo must have both bar and baz enabled foo[-bar,baz] foo must have bar disabled and baz enabled Conditional USE Dependencies Table 6.3. Syntax Examples Compact Form Equivalent Expanded Form foo[bar?] bar? ( foo[bar] ) !bar? ( foo ) foo[-bar?] bar? ( foo ) !bar? ( foo[-bar] ) foo[bar=] bar? ( foo[bar] ) !bar? ( foo[-bar] ) foo[bar!=] bar? ( foo[-bar] ) !bar? ( foo[bar] )
(In reply to comment #63) > foo[bar!=] bar? ( foo[-bar] ) !bar? ( foo[bar] ) Could we change that to foo[-bar=] eventually? I rather dislike the current syntax as - it's inconsistent with the ? operator, negation should use the same syntax for all variants - wrt use flags, ! is usually implemented as a prefix operator
(In reply to comment #64) > (In reply to comment #63) > > foo[bar!=] bar? ( foo[-bar] ) !bar? ( foo[bar] ) > > Could we change that to foo[-bar=] eventually? I rather dislike the current > syntax as > - it's inconsistent with the ? operator, negation should use the same syntax > for all variants Well, I'd describe != as an "inversion" rather than a "negation". They're two distinctly different operations. > - wrt use flags, ! is usually implemented as a prefix operator It still is a prefix operator if you view it as prefixing the = symbol. Also, practically every language I can think of has a != operator.
(In reply to comment #65) > Well, I'd describe != as an "inversion" rather than a "negation". They're two > distinctly different operations. ... > It still is a prefix operator if you view it as prefixing the = symbol. Also, > practically every language I can think of has a != operator. Guess the problem is that I see != here as two distinct operators. IMO reading the != as "not equal" like in other languages doesn't make much sense here as we only have one operand (the current state of "bar"). I read the = more as "assign to state of operand", and != would be "assign to inversed state", which is however the same as "assign to state" if the operand is negated. Same logic applies to the ? operator (which I read as "assign if operand"). So either that should be changed to !? (which looks quite stupid) as well if you see ! as a prefix to =, or the syntax should be changed as suggested in comment #64. The current situation is just inconsistent and therefore silly.
(In reply to comment #66) > So either that > should be changed to !? (which looks quite stupid) as well if you see ! as a > prefix to =, or the syntax should be changed as suggested in comment #64. The > current situation is just inconsistent and therefore silly. Seems reasonable. Maybe we should also swap the - character with a ! character in all the conditionals, so it's consistent with the pre-existing conditional syntax? Then we'd have something like this: Compact Form Equivalent Expanded Form foo[bar?] bar? ( foo[bar] ) !bar? ( foo ) foo[!bar?] bar? ( foo ) !bar? ( foo[-bar] ) foo[bar=] bar? ( foo[bar] ) !bar? ( foo[-bar] ) foo[!bar=] bar? ( foo[-bar] ) !bar? ( foo[bar] )
(In reply to comment #67) > Seems reasonable. Maybe we should also swap the - character with a ! character > in all the conditionals, so it's consistent with the pre-existing conditional > syntax? That works for me too.
I've released sys-apps/portage-2.2_rc5 and it supports a new EAPI="2_pre1" which has the conditional syntax shown in comment #67. The previous experimental EAPI="2_pre0" value is no longer supported.
*** Bug 236147 has been marked as a duplicate of this bug. ***
*** Bug 256519 has been marked as a duplicate of this bug. ***
