Summary: | method for handling conflicting USE flags at --pretend time required | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Ciaran McCreesh <ciaran.mccreesh> |
Component: | Core - Ebuild Support | Assignee: | PMS/EAPI <pms> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | axxo, blubb, ed, greg_g, m.debruijne, pclouds, php-bugs, ramereth, robbat2, vericgar |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | in-eapi-4 | ||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 174380 |
Description
Ciaran McCreesh
2004-12-28 12:11:57 UTC
Could someone please summarize possible approaches to solve this? I did search gentoo-dev archives but found nothing (maybe i used wrong keywords) Ok, first option: pkg_depcheck() { if use qt && use gtk ; then eerror "Error calculating dependencies for ${P}:" eerror "The qt and gtk USE flags are mutually exclusive for this package." eerror "Please unset one of these flags. This can be done on a per-package" eerror "basis using /etc/portage/package.use, which is documented in man 5" eerror "portage." die "Error checking USE flags for ${PN}" fi } Except I'd offload the message displays into an eclass so that we get totally consistent behaviour between packages... Something like: pkg_depcheck() { depcheck-mutually-exclusive "gtk" "qt" } The other option, suggested by Nick, is something like: USE_CONFLICTS=" gtk? ( !qt ) qt? ( !gtk )" which is probably faster, but is kinda difficult to work with. Although, I guess that could be offloaded into an eclass too... USE_CONFLICTS=" $(useconflicts-make-mutually-exclusive gtk qt )" *** Bug 84937 has been marked as a duplicate of this bug. *** pkg_depcheck needs to be more generic than just stuff in make.conf. From my duplicate bug, I gave this as one of the examples ==== If you try upgrade from openldap-2.1 to 2.2 and you have an LDAP server on that machine, without following the upgrade instructions, it WILL corrupt your database. To work around this, pkg_setup detects if you are doing an upgrade from 2.1 to 2.2 (and you have a local database), and displays the upgrade instructions, then fails out. Again, if this happens N hours into a build process, it stops the automated build. ==== the pkg_depcheck() approach looks far saner to me as it could be used for all kind of stuff, not only dependency checking. however, as it is run everytime the dependencies are calculated, it would make the cache completely useless and massively slow down dep calculation. best way to workaround this issue i can think of would be to set a "i've got a pkg_depcheck function" flag in the cache and have portage only source the ebuild when it is set. as most packages won't need pkg_depcheck, this shouldn't hurt too much. It would not have to make the cache useless if it's done as a seperate stage. Do the dep calculation, then run pkg_depcheck for every package, then do the merge for each package. This would put all the warnings and errors after the deptree is built but before anything is started to be merged. Hi, Not trying to spam, just wondering if this issue is still open with the new portage? If so, the pkg_depcheck looks sane to me too, if it can be done as a separate stage as described. 177860 is a better bug for this *** This bug has been marked as a duplicate of bug 177860 *** |