| Summary: | use dependencies should allow specification of default assumptions about flags missing from IUSE | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Pacho Ramos <pacho> |
| Component: | Current packages | Assignee: | PMS/EAPI <pms> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | esigra, kde |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=916952 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 174380, 245954 | ||
|
Description
Pacho Ramos
2008-11-28 13:59:09 UTC
This is basically a shortcomming of the current USE_EXPAND system. Requiring to have the dead ugly IUSE+=linguas_FOO additions before setting the dependencies, to be able to test accordingly is even more messy. Well, this affects lots of packages... Well kde4 eclasses tell the user to emerge the package if detect some misc package with linguas enabled. Maybe we should do the same for kde3 :] This is equally broken, since it requires user interaction, Thomas.
The requirement is "foo[?bar?baz?]" with foo _not_ being a dependency in the case neither bar nor baz being enabled. I could live with another modifier than the first "?" of course (e.g. "*" and maybe also "+" to denote "one of" with the latter requiring at least one use flag to be set, which would be really useful), but this is more a deficiency in Portage, otherwise the following example code excerpt would work, without adding the kde-i18n dependency, unless needed.
LANGS="de es fr it
LANGS_IUSE=""
for X in ${LANGS} ; do
LANGS_IUSE="${LANGS_IUSE} linguas_${X}"
done
IUSE="${IUSE} ${LANGS_IUSE}"
if [ -n "${LANGS_IUSE}" ] ; then
RDEPEND="${RDEPEND}
kde-base/kde-i18n[`echo ${LANGS_IUSE} |sed -e "s: :?,:g"`?]"
fi
The more I think about it, this is a Portage issue. Not tex specific, so un'cc'ing you, tex team. Please readd yourself, in case you're interested in this bug.
Well with usedep it is maybe good idea but then you get to the dependency issue due to not knowing if i18n and l10n has the specified lingua in iuse. :( I will ask Zac about it... Will report his suggestions later :] Ok after discusion with Zac he suggested this: || ( cat/app[flag] cat/app ) so result for kde4 is this: http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=commit;h=d126640d3551ff1eb76073b772eb4ddaecdbcdf6 for kde3 we have to eapi2fy the eclass first and even then it must be sadly handled by has_use basic eapi2fing of kde3 eclasses is sent to tampakrap and yngwin (missing src_prepare calls [can be blank ones calling only base_apply_patches]) :] (In reply to comment #3) > The requirement is "foo[?bar?baz?]" with foo _not_ being a dependency in the > case neither bar nor baz being enabled. So, uh, "bar? ( foo[bar][baz] ) baz? ( foo[bar][baz] )" or what? (In reply to comment #5) > Ok after discusion with Zac he suggested this: > || ( cat/app[flag] cat/app ) No, that's illegal. app[flag] when app doesn't have flag explicitly listed in IUSE is undefined behaviour, and the package manager should be warning or erroring if it encounters it. (In reply to comment #6) > (In reply to comment #5) > > Ok after discusion with Zac he suggested this: > > || ( cat/app[flag] cat/app ) > > No, that's illegal. app[flag] when app doesn't have flag explicitly listed in > IUSE is undefined behaviour, and the package manager should be warning or > erroring if it encounters it. If the flag isn't in IUSE, portage just treats it like any other unsatisfiable dependency. Doesn't that seem reasonable? (In reply to comment #7) > If the flag isn't in IUSE, portage just treats it like any other unsatisfiable > dependency. Doesn't that seem reasonable? Not really. It was deliberately specified as undefined behaviour because there are several 'reasonable' interpretations of what it could mean. You could just as easily argue that if there's no flag, the package manager should pretend that flag is there but off. (In reply to comment #8) > You could just > as easily argue that if there's no flag, the package manager should pretend > that flag is there but off. That would be a somewhat unreliable assumption to make. (In reply to comment #9) > (In reply to comment #8) > > You could just > > as easily argue that if there's no flag, the package manager should pretend > > that flag is there but off. > > That would be a somewhat unreliable assumption to make. *Any* assumption is unreliable, which is why it's specified as being undefined behaviour, and why the package manager should yell if it encounters it. (In reply to comment #5) > Ok after discusion with Zac he suggested this: > || ( cat/app[flag] cat/app ) Isn't that the same as cat/app anyway? If cat/app[flag] isn't satisfied, then the package manager will fall back on plain cat/app, so the state of flag ultimately doesn't matter. Based on the IRC discussion in my backlog, it sounds as though you want an equivalent of built_with_use --missing for use deps. In Exherbo we're using cat/app[flag(+)], with the (+) meaning --missing true, and (-) for --missing false. (In reply to comment #5) > Ok after discusion with Zac he suggested this: > || ( cat/app[flag] cat/app ) Hu? No. (In reply to comment #6) > So, uh, "bar? ( foo[bar][baz] ) baz? ( foo[bar][baz] )" or what? No, basically a flag indicating foo is not part of the dependency list, when none of bar, baz are set. Or to put it in some pseudo code "USE=[bar,-baz]" --> "foo[?bar?,baz?]" --> "foo[bar]" "USE=[-bar,-baz]" --> "foo[?bar?,baz?]" --> "" (In reply to comment #12) > (In reply to comment #6) > > So, uh, "bar? ( foo[bar][baz] ) baz? ( foo[bar][baz] )" or what? > > No, basically a flag indicating foo is not part of the dependency list, when > none of bar, baz are set. Or to put it in some pseudo code > > "USE=[bar,-baz]" --> "foo[?bar?,baz?]" --> "foo[bar]" > "USE=[-bar,-baz]" --> "foo[?bar?,baz?]" --> "" So... bar? ( baz? ( foo[bar,baz] ) !baz? ( foo[bar] ) ) !bar? ( baz? ( foo[bar,baz] ) !baz? ( ) ) or something? Expand it fully please, I'm still not really sure what you're trying to do. (In reply to comment #13) > So... > > bar? ( baz? ( foo[bar,baz] ) !baz? ( foo[bar] ) ) > !bar? ( baz? ( foo[bar,baz] ) !baz? ( ) ) > > or something? Expand it fully please, I'm still not really sure what you're > trying to do. > Exactly, only the result of !bar? ( !baz? ( ) )) is required to be empty, instead of foo without use flags set. Not that it wouldn't be "fun" to torture Portage with 20 or 30 use expanded dependencies trying to express this with a forrest of deeply nested parentheses... Just use the fully expanded form. The shortcuts are only there for the very common cases -- anything more complicated doesn't get a shortcut. # add a dependency over kde-l10n if EAPI4 is around
if [[ ${KDEBASE} != "kde-base" ]] && [[ -n ${KDE_LINGUAS} ]] && has "${EAPI:-0}" 4; then
usedep=''
for _lingua in ${KDE_LINGUAS}; do
[[ -n ${usedep} ]] && usedep+=","
usedep+="linguas_${_lingua}(+)?"
done
# if our package has lignuas pull in kde-l10n with selected lingua
kderdepend+=" $(add_kdebase_dep kde-l10n ${usedep})"
unset usedep _lingua
fi
So we can consider this fixed in eapi4...
(In reply to comment #16) > So we can consider this fixed in eapi4... Right, EAPI 4-style USE-DEP-DEFAULTS in section 9.2.5.4 of PMS. |