Bug 2272 - portage: ability to depend on USE flags being enabled
|
Bug#:
2272
|
Product: Portage Development
|
Version: unspecified
|
Platform: x86
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: dev-portage@gentoo.org
|
Reported By: erichey2@attbi.com
|
|
Component: Unclassified (old)
|
|
|
URL:
|
|
Summary: portage: ability to depend on USE flags being enabled
|
|
Keywords: InSVN
|
|
Status Whiteboard:
|
|
Opened: 2002-04-30 06:24 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.
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. ***
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.
*** Bug 34905 has been marked as a duplicate of this bug. ***
*** Bug 38907 has been marked as a duplicate of this bug. ***
Created an attachment (id=24275) [details]
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.
(From update of attachment 24275 [details])
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. ***