I also vote for this. Some of the use flags descriptions require you to dig into the ebuild and google before you get an idea of what the use flag is supposed to do, quite annoying indeed.
Roman On Tue, 8 Feb 2005 21:22:33 +0100, Marius Mauch <[EMAIL PROTECTED]> wrote: > On Tue, 8 Feb 2005 13:33:38 +0100 > Paul de Vrieze <[EMAIL PROTECTED]> wrote: > > > On Tuesday 08 February 2005 11:44, Thomas de Grenier de Latour wrote: > > > On Tue, 8 Feb 2005 11:30:20 +0100 > > > > > > Paul de Vrieze <[EMAIL PROTECTED]> wrote: > > > > - Have a variable per useflag. Not easy > > > > > > Yep, it needs to be a single variable to fit in the cache and be > > > accessible by simple aux_get calls. > > > > > > > - Have different markers. Something like marking the useflag > > > > with colons > > > > e.g.: ":debug: Enable debugging support :X: Make the client > > > > aware of the X mouse" > > > > > > I would add parenthesis, something like that: > > > > I think square or angle brackets might be better. We must use markers > > that are not normally used in description texts. While supporting > > nesting is possible it makes things harder than they need to be. > > > > > > USE_DESC=" \ > > > foo:(Add foolib support. Warning: that replaces libbar.) \ > > > X:(Add an experimental X client, still a bit instable.)" > > So now you see why I don't want it in the ebuilds. Also it has the > potential to add a lot of redundancy, especially if you keep in mind > that the original idea was to give more detailed explanation of USE > flags. IMO it should be handled the same way as the long package > descriptions. > > Marius > > -- > Public Key at http://www.genone.de/info/gpg-key.pub > > In the beginning, there was nothing. And God said, 'Let there be > Light.' And there was still nothing, but you could see a bit better. > > > -- [email protected] mailing list
