On Tue, Jun 7, 2016 at 3:03 PM, Brian Dolbec <dol...@gentoo.org> wrote: > > an ordered list of the gui toolkits in their preferred order of > desirability. This should be an all inclusive list. Note: these are > subject to package.use setting overrides. >
This has been my thought as well. This really isn't limited to graphics toolkits either. It probably requires PMS support to do well, though maybe we could get away with an eclass of some kind (but messing with USE and dependencies dynamically seems problematic in an eclass). Let's take a USE_EXPAND-like ordered list of flags: A="a c d e" A package could support exactly one or any number of these flags. A package could require one or none of these flags. The package would somehow express whether it handles only one and whether it requires any. This might be done by calling a function and passing the list of supported flags and A. Then portage would expand this into a list of USE flags that get applied. If only one is supported then the effective USE flag will be the first flag in the list that the package supports. If it supports more than one then the effective flags would include all the flags the package supports which are in the list. If the package requires a flag then if in the end no flags intersected then portage will die with an error. >From that point the flags work like ordinary USE flags - they get added to USE and can be used to pull in dependencies or turn on features. Since they've been pre-filtered down to one or many and requirements were dealt with you generally don't need rat-nests of conditionals to deal with these situations all over the place. I can still see some issues here. Maybe a package can support up to one qt option and up to one gtk option. Maybe the list of supported flags won't be "qt4 qt5 gtk2 gtk3" but rather something like " ( qt4 qt5 ) ( gtk2 gtk3 ) " or some other syntax that expresses the same sort of thing. The goal should be to make this more declarative and less procedural, which is the general trend here. -- Rich
