Mark Loeser wrote:
Here is a newer revision of the GLEP.  I still have multiple methods of
solving this problem (mostly because I want and *need* input from people
as to what they would prefer).  Please tell me what you would want to
use so I can come up with a more precise specification.  What exactly do
we need this system to do that we can't do now?  Is overriding the USE
flag with use.local.desc sufficient and we just need to document the
current solution properly?

Please...let me know how you feel about this.


What do people think of this?

a) Keep use.desc as it is: a list of common flags and a short general description of their meaning.

b) Keep use.local.desc as it is: a list of per-package flags that are specific to one to a few ebuilds (i think 5 is the number though i think 10 is more appropriate, but that's not relevant to this discussion). Again, each has a short description.

c) Allow flags from use.desc to also exist in use.local.desc. In the case that a flag for a package exists in both, the use.local.desc description overrides the use.desc one. This allows a more specific per-package description of global flags.

d) Allow long descriptions in a package's metadata.xml, as some have begun to do already, for cases where more info is needed. For example I'd like to explain exactly what the bindist flag on freetype does and what legal implications disabling it can have.

The reason I suggest we do it this way is it's very close to what we're already doing now. The only thing we'd need to do is decide it's okay to do (c) and adapt our various utils to use the use.local.desc description when both exist. I actually planned on proposing something like this about a year ago but never got around to it. But at the time I did some poking and found that several of our utils already did the right thing while the others needed minor adjustments (I think I had a one-line patch for equery). We also needn't worry about breaking 3rd party tools. The worst that would happen is they'd display the use.desc description, which is what they do now.

On the other hand, if there are any far-reaching changes we need made to the USE flag system - any features we wish we had or misfeatures we wish we didn't - now would be a good time to address them.

fonts,                                            by design, by neglect
gcc-porting,                              for a fact or just for effect
wxwindows @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

-- mailing list

Reply via email to