On Tuesday 27 September 2005 21:35, Chris Gianelloni wrote: > On Tue, 2005-09-27 at 18:23 +0900, Jason Stubbs wrote: > > 1) What to do if nothing is set? > > 2) What to do if an invalid value is set? > > Install everything. If everything cannot be installed, due to > incompatibilities, then die.
This causes trouble though as it has in your case below. > > Of these, 1) and 2) absolutely must be whittled down to one standard. > > Preferably, 3) should follow one standard as well. Not following one > > standard will simply lead to users thinking, "but that's not what I > > wanted..!" It will also lead portage to do needless recompiles due to the > > information available being limited. > > > > Next, storing the information of what choices are valid. If it can be > > guaranteed that all packages supporting a variable (LINGUAS for example) > > have exactly the same list of choices in all cases, storing the choice > > list in a global file is acceptable. If not, each package absolutely must > > list what choices are available for it. Not doing so means the flow may > > head into 2) in the above list even when the user has set a valid choice > > for a different package. Again, it's against the user's expectations. > > Let's take an example of this... Neverwinter Nights. Currently, it > installs the language packs via LINGUAS. If nothing is selected via > LINGUAS, then it installs English, which is considered the default. > Unfortunately, even trying to add -linguas_fr to package.use, still > results in the French language pack being installed over the English. I > honestly do not know how to correct this. I see a couple things that > would be needed. For one, things in USE_EXPAND would need to be > negate-able in package.use. The problem with NWN is that only one > language pack may be installed at any given time due to them providing > the same files. The current implementation extends the USE flags with those derived from USE_EXPAND after everything has been cascaded. It was likely done this way out of ease of implementation, but now that USERLAND and such are using it... > I would love to see this fixed. I'm guessing that this would mean > defining all of the USE_EXPAND capabilities in IUSE, correct? That is one solution that isn't hard to support, can be done quickly(?) on the ebuild side and is already implemented (though unreleased) on the portage side. However, it really seems to me that USE_EXPAND just doesn't expand well (pardon the pun ;). Thinking about it, USE has its own set of issues as well. There are number of cases in the tree of "you can have A or B, but not both" and "you must pick at least A or B". There's also "if A isn't set then B and C aren't used". Long term solution would seem to be to completely revamp the USE/USE_EXPAND/ARCH-USERLAND-* system to clear out at least the existing pitfalls and hopefully not fall into new ones (and of course maintain backward compatibility). If there's agreement in that, it might not be the best bet to put a whole lot of work into getting USE_EXPAND working "correctly"; that is to say, getting things following the above rules is perhaps not worth the effort. As it stands, it would seem package.env support, a way to express dependencies between USE flags, a way to express USE_EXPAND choices, a way to express limits on those choices and a way to protect profile variables (just to begin with) are all required to get the current system working a bit more smoothly. Seems very much like a bandaid on a bandaid on a ... Bah.. I'm mumbling. I really don't mind what the solution is in the short term as long as the USE_EXPAND choices get delivered to the users and that how those choices work is clear. If the solution I've already done a patch for isn't acceptable to everyone, find a solution that is and I'll support it accordingly. I just don't want it to sit around and gather more dust. -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
