So folks seem to want things both ways. Some people believe that USE_EXPAND'd variables are private:
|| I have yet to be enlightened on any merit of USE_EXPAND is so perhaps || you could explain as to why there should be || user-configured-yet-undocumented options for ebuilds? More precisely, || how should they be documented if not via use.desc? | |1. Because for things like LINGUAS, there are arbitrarily many legal |values, and documenting them all and keeping the list up to date would |be extremely difficult. | |2. Because USE_EXPAND is used for special USE things like arch and |userland, and because we undocumented the special arch USE flags |because they're not user settable. That leaves a couple of things, first off, how do users figure out that a particular setting affects an ebuild. If I have no VIDEO_CARDS set, for example, how do I as a user figure out that that the new modular X ebuilds actually use VIDEO_CARDS? Secondly, some USE_EXPAND'd things are user-settable, and some are not. Arguably, some may belong in IUSE, others are just not appropriate ( VIDEO_CARDS and LINGUAS both being rather large and difficult to maintain. The current state of things is that: 1. Repoman complains to developers when they use USE_EXPAND in IUSE and there are not entries in use.desc This check for USE_EXPAND'd variables can be turned off, if the community feels that USE_EXPAND should remain undocumented. Or we can commit Diego's patch that reads USE_EXPAND descriptions from $PORTDIR/profiles/desc/USE_EXPAND.desc 2. Portage complains about USE_EXPAND flags not in IUSE when they are used, because they are not user settable. This ties into the above, either USE_EXPAND flags modify ebuilds publically (IUSE) or they modify it privately ( no IUSE ). I don't really want to see it both ways, as we then need a constant list of USE_EXPAND flags that are supposed to set off warnings versus those that don't. Or we just kill the warnings for any USE_EXPAND variable, which I hope the QA team will comment on. 3. Jason Stubbs has commited code in portage 2.1 to show USE_EXPAND flags in output. I'm not sure who likes or dislikes this, but depending on that outcome of this discussion, that code may need to be modified. Conclusion: Either USE_EXPAND always goes in IUSE, or USE_EXPAND never goes in IUSE. If you want USE_EXPAND that sometimes goes in IUSE and sometimes doesn't you better have a good plan for keeping those lists of proper USE_EXPAND flags and improper flags in sync. I mean I'd love to do it that way, but I'll bet those lists get old and nasty and we will have people complaining about QA warnings that they thought were fixed or that there were no QA warnings when there should have been...etc.. -Other ideas are always welcome; I'd prefer to get this solved soon. -Alec Warner
signature.asc
Description: OpenPGP digital signature
