2272 2002-04-30 06:24 0000 portage: ability to depend on USE flags being enabled 2009-01-27 14:32:26 0000 1 1 1 Unclassified Portage Development Unclassified (old) unspecified x86 Linux RESOLVED FIXED InSVN P2 normal --- 23464 64289 74435 142941 155723 233213 1 erichey2@attbi.com dev-portage@gentoo.org 3.14159@gmx.net aaron123456789@gmail.com adrian.fruehwirth@gmx.at alpeterson@wsu.edu ansla80@yahoo.com aoz.syn@gmail.com aqu3l@go2.pl arne_bab@web.de azarah@gentoo.org basic@mozdev.org ben@xsusio.com blubb@gentoo.org bugs@dev.gentooexperimental.org carpaski@gentoo.org caster@gentoo.org chris_se@gmx.net chutz@gg3.net clmason@gmail.com daniel.goertzen@norscan.com darkside@gentoo.org dberkholz@gentoo.org efagerho@cc.hut.fi eprparadocs@gmail.com felix.schuster@gmx.at ferringb@gmail.com flash3001@yahoo.com flonai@gmx.de foser@gentoo.org frares@gmail.com gentoo-bugs@allenjb.me.uk george@gentoo.org h3y@esaurito.net hannes@gentoo.org hc@poweredbymice.com hkbst@gentoo.org hramrach@centrum.cz ikorot@earthlink.net imirkin@mit.edu jarausch@igpm.rwth-aachen.de jehan@zemarmot.net jer@gentoo.org john_r_graham@mindspring.com kanaka@gentoo.org latexer@gentoo.org m.debruijne@matrict.nl mail@eliasprobst.eu mail@peter-thomassen.de mcconachieneal@mail.com mholzer@gentoo.org michael.e.harris@gmail.com paolo.gabrielli@gmail.com parasietje@gmail.com redbaron@hitv.ru rockoo@gmail.com sdh33@cornell.edu seemant@gentoo.org serkan@gentoo.org simoneau@ele.uri.edu smithj@gentoo.org steffen@schaumburger.info StormByte@gmail.com tcunha@gentoo.org ticho@gentoo.org usata@gentoo.org uzytkownik2@gmail.com vrtladept@gmail.com wolf31o2@wolf31o2.org xoen.gnu@gmail.com znxster@gmail.com erichey2@attbi.com 2002-04-30 06:24:07 0000 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. seemant@gentoo.org 2002-04-30 06:45:32 0000 this has come up so many times, it is not even funny any more. Daniel, we might want to give this some serious consideration. azarah@gentoo.org 2002-04-30 15:41:33 0000 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. vapier@gentoo.org 2002-09-26 10:13:35 0000 *** Bug 8401 has been marked as a duplicate of this bug. *** azarah@gentoo.org 2002-10-12 14:11:17 0000 Any news on this front ? hannes@gentoo.org 2002-10-20 17:00:11 0000 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. george@gentoo.org 2002-10-24 00:26:41 0000 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 azarah@gentoo.org 2002-12-02 05:14:56 0000 Could this be resolved some time soon ? If you need help, just tell us how. g2boojum@gentoo.org 2002-12-04 10:57:49 0000 *** Bug 7554 has been marked as a duplicate of this bug. *** trapni@gentoo.org 2003-01-12 01:08:41 0000 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. mholzer@gentoo.org 2003-10-12 15:11:48 0000 portage can do this now vapier@gentoo.org 2003-12-01 21:04:01 0000 actually, it still cant vapier@gentoo.org 2003-12-02 21:31:41 0000 *** Bug 34905 has been marked as a duplicate of this bug. *** vapier@gentoo.org 2004-01-21 04:17:59 0000 *** Bug 38907 has been marked as a duplicate of this bug. *** tom.gl@free.fr 2004-01-23 02:32:22 0000 Created an attachment (id=24275) 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." ; } } foser@gentoo.org 2004-02-10 15:12:38 0000 *** Bug 41170 has been marked as a duplicate of this bug. *** vapier@gentoo.org 2004-02-13 10:58:05 0000 *** Bug 41452 has been marked as a duplicate of this bug. *** ferringb@gmail.com 2004-07-22 00:48:55 0000 *** Bug 57828 has been marked as a duplicate of this bug. *** latexer@gentoo.org 2004-08-05 08:08:35 0000 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? foser@gentoo.org 2004-08-09 10:56:55 0000 *** Bug 53467 has been marked as a duplicate of this bug. *** ferringb@gmail.com 2004-08-10 23:43:13 0000 *** Bug 20326 has been marked as a duplicate of this bug. *** jstubbs@gentoo.org 2004-08-11 04:22:50 0000 I guess I didn't do that properly.. :/ andrew@operationaldynamics.com 2004-11-10 16:29:08 0000 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 jstubbs@gentoo.org 2004-11-11 03:56:53 0000 /me hates duplicate mails. Not a chance this will be in the 2.0.51 series, but should be in what comes after. tom.gl@free.fr 2004-12-06 19:14:56 0000 (From update of attachment 24275) Marking this patch obsolete since a similar hack has been included in eutils.eclass. vapier@gentoo.org 2004-12-14 21:01:15 0000 *** Bug 74328 has been marked as a duplicate of this bug. *** john@milsson.nu 2005-01-31 07:45:56 0000 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--- vapier@gentoo.org 2005-01-31 07:49:22 0000 the current work around is to use the function 'built_with_use' in the eutils eclass hanno@gentoo.org 2005-02-13 11:21:48 0000 *** Bug 81461 has been marked as a duplicate of this bug. *** swegener@gentoo.org 2005-02-28 07:08:38 0000 *** Bug 83554 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2005-09-20 10:09:20 0000 *** Bug 106685 has been marked as a duplicate of this bug. *** jstubbs@gentoo.org 2005-10-07 09:20:04 0000 *** Bug 51584 has been marked as a duplicate of this bug. *** azarah@gentoo.org 2005-11-01 00:58:45 0000 *** Bug 111031 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2005-11-25 17:16:24 0000 *** Bug 113599 has been marked as a duplicate of this bug. *** andrew.frink@gmail.com 2006-02-14 07:03:37 0000 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 vapier@gentoo.org 2006-03-30 10:51:00 0000 *** Bug 128123 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2006-05-11 13:11:56 0000 *** Bug 133058 has been marked as a duplicate of this bug. *** antarus@gentoo.org 2006-06-11 10:53:42 0000 *** Bug 136448 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2006-06-12 13:58:53 0000 *** Bug 136578 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2006-07-30 12:12:48 0000 *** Bug 142209 has been marked as a duplicate of this bug. *** felix.schuster@gmx.at 2006-09-21 02:45:30 0000 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. jakub@gentoo.org 2006-09-28 08:18:54 0000 *** Bug 149423 has been marked as a duplicate of this bug. *** zmedico@gentoo.org 2006-09-29 12:59:26 0000 *** Bug 149556 has been marked as a duplicate of this bug. *** genone@gentoo.org 2006-10-26 15:47:14 0000 *** Bug 152930 has been marked as a duplicate of this bug. *** zmedico@gentoo.org 2006-10-29 15:51:09 0000 *** Bug 153366 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2006-11-22 10:10:19 0000 *** Bug 155945 has been marked as a duplicate of this bug. *** expose@luftgetrock.net 2006-12-13 09:10:29 0000 Why is "built_with_use" only a work around and not the solution, as stated by SpanKY/vapier in comment #27 ? kanaka@gentoo.org 2006-12-13 09:15:12 0000 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. swegener@gentoo.org 2007-04-21 15:18:28 0000 *** Bug 175444 has been marked as a duplicate of this bug. *** mail@eliasprobst.eu 2007-07-25 11:04:43 0000 Any news here? Has calculation of USE-flags in dependencies been considered for EAPI-1 proposals? zmedico@gentoo.org 2007-08-23 23:04:44 0000 *** Bug 189966 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2007-08-31 09:55:02 0000 *** Bug 190855 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2007-09-05 11:55:17 0000 *** Bug 191370 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2007-09-21 15:49:26 0000 *** Bug 193335 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2007-10-31 21:53:06 0000 *** Bug 197666 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2007-11-05 07:09:52 0000 *** Bug 198126 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2007-11-17 19:07:50 0000 *** Bug 199460 has been marked as a duplicate of this bug. *** zmedico@gentoo.org 2008-01-19 04:59:20 0000 *** Bug 206613 has been marked as a duplicate of this bug. *** jakub@gentoo.org 2008-02-04 20:59:53 0000 *** Bug 208872 has been marked as a duplicate of this bug. *** parasietje@gmail.com 2008-05-25 11:08:39 0000 Happy 6th birthday, bug 2272! (yes, I'm being an unconstructive asshole ;) ) caster@gentoo.org 2008-05-26 07:32:52 0000 (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. genone@gentoo.org 2008-06-10 16:08:13 0000 Fixed in or before 2.2_pre8 steffen@schaumburger.info 2008-06-11 05:19:02 0000 Brilliant, thanks :) Somewhat off-topic - does anyone happen to know if this works in paludis, too? zmedico@gentoo.org 2008-07-28 23:07:39 0000 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] ) genone@gentoo.org 2008-07-29 00:51:12 0000 (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 zmedico@gentoo.org 2008-07-29 03:00:18 0000 (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. genone@gentoo.org 2008-07-29 21:13:00 0000 (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. zmedico@gentoo.org 2008-07-30 01:27:10 0000 (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] ) genone@gentoo.org 2008-07-30 02:27:49 0000 (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. zmedico@gentoo.org 2008-07-30 10:23:07 0000 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. zmedico@gentoo.org 2008-08-29 22:19:33 0000 *** Bug 236147 has been marked as a duplicate of this bug. *** serkan@gentoo.org 2009-01-27 14:32:26 0000 *** Bug 256519 has been marked as a duplicate of this bug. *** 24275 2004-01-23 02:32 0000 have_flags.patch have_flags.patch text/plain LS0tIGJpbi9wb3J0YWdlcS5vcmlnCTIwMDQtMDEtMjMgMTA6MDk6NTguMDAwMDAwMDAwICswMTAw CisrKyBiaW4vcG9ydGFnZXEJMjAwNC0wMS0yMyAxMTowNzo0OS41ODczMzE5NTUgKzAxMDAKQEAg LTYxLDYgKzYxLDI2IEBACiAJZXhjZXB0IEtleUVycm9yOgogCQlzeXMuZXhpdCgxKQogCitkZWYg aGF2ZV9mbGFncyhhcmd2KToKKwkiIiI8cm9vdD4gPGNhdGVnb3J5L3BhY2thZ2U+IFs8dXNlX2Zs YWc+XSsKKwlSZXR1cm5zIDAgaWYgYWxsIHRoZSBtYXRjaGluZyBwYWNrYWdlcyBoYXZlIHRoZSBy ZXF1ZXN0ZWQgVVNFIGZsYWdzLCAwIG90aGVyd2lzZS4KKwkiIiIKKwlpZiAobGVuKGFyZ3YpIDwg Myk6CisJCXByaW50ICJFUlJPUjogaW5zdWZmaWNpZW50IHBhcmFtZXRlcnMhIgorCQlzeXMuZXhp dCgyKQorCW15ZmxhZ2xpc3Q9YXJndlsyOl0KKwlteXZkYmFwaT1wb3J0YWdlLmRiW2FyZ3ZbMF1d WyJ2YXJ0cmVlIl0uZGJhcGkKKwl0cnk6CisJCW15cGtnbGlzdD1teXZkYmFwaS5tYXRjaChhcmd2 WzFdKQorCQlmb3IgbXlwa2cgaW4gbXlwa2dsaXN0OgorCQkJbXlwa2dmbGFncz1zdHJpbmcuc3Bs aXQobXl2ZGJhcGkuYXV4X2dldChteXBrZyxbJ1VTRSddKVswXSkKKwkJCWZvciBteWZsYWcgaW4g bXlmbGFnbGlzdDoKKwkJCQlpZiBub3QgKG15ZmxhZyBpbiBteXBrZ2ZsYWdzKToKKwkJCQkJc3lz LmV4aXQoMSkKKwkJc3lzLmV4aXQoMCkKKwlleGNlcHQgS2V5RXJyb3I6CisJCXN5cy5leGl0KDEp CisKIAogZGVmIG1hc3NfYmVzdF92ZXJzaW9uKGFyZ3YpOgogCSIiIjxyb290PiBbPGNhdGVnb3J5 L3BhY2thZ2U+XSsKLS0tIGJpbi9lYnVpbGQuc2gub3JpZwkyMDA0LTAxLTIzIDEwOjI4OjI4LjAw MDAwMDAwMCArMDEwMAorKysgYmluL2VidWlsZC5zaAkyMDA0LTAxLTIzIDEwOjMxOjE1LjU5MDg1 NDExMiArMDEwMApAQCAtMjAyLDYgKzIwMiwxNiBAQAogCWZpCiB9CiAKK2hhdmVfZmxhZ3MoKSB7 CisJIyByZXR1cm4gc2hlbGwtdHJ1ZS9zaGVsbC1mYWxzZSBpZiBhbGwgbWF0Y2hpbmcgcGtncyBo YXZlIHRoZSByZXF1ZXN0ZWQgZmxhZ3MuCisJIyBUYWtlcyBhIHNpbmdsZSBkZXBlbmQtdHlwZSBh dG9tcyBhbmQgYSBVU0UgZmxhZyBsaXN0LgorCWlmIC91c3IvbGliL3BvcnRhZ2UvYmluL3BvcnRh Z2VxICdoYXZlX2ZsYWdzJyAiJHtST09UfSIgIiRAIjsgdGhlbgorCQlyZXR1cm4gMAorCWVsc2UK KwkJcmV0dXJuIDEKKwlmaQorfQorCiBiZXN0X3ZlcnNpb24oKSB7CiAJIyByZXR1cm5zIHRoZSBi ZXN0L21vc3QtY3VycmVudCBtYXRjaC4KIAkjIFRha2VzIHNpbmdsZSBkZXBlbmQtdHlwZSBhdG9t cy4K