> Hmm, maybe yes. I would not be against an "emerge -p -vv" mode
> which would display this USE flag desriptions (not the standard
> ones sure, only the ones redefined per-package). That sounds like
> the easier way to know that some of them are highly encouraged, or
> discouraged, or a bit different from what they mean in general,
> etc.
>
I'd have to agree here, I would personally enjoy this, I often wonder
what things do as far as USE flags, I just hope they do what I think
they do. This example may be stupid but I recently setup gkrellmd on my
router and server for monitoring and I was seriously curious what
emerging gkrellm with -X would do and I realize it sets it up for just
gkrellmd and not the regular gkrellm and gkrellm2 (and this is what I
want, exactly what I want I just did not know that this would be the
outcome and I am quite pleased this was the outcome) I think that the
USE flags that are specific to the program and or have some serious
difference in the program should be defined in the ebuild itself. Just
my opinion on the matter.On Mon, 2005-02-07 at 21:50 +0100, Thomas de Grenier de Latour wrote: > On Mon, 7 Feb 2005 16:19:06 +0100 > Paul de Vrieze <[EMAIL PROTECTED]> wrote: > > > I would be happy to add it to metadata.xml. I think it would be > > easier to do so, and the tools might come with the possibility. > > As an occasional ebuild contributor, i would prefer this directly > in ebuilds rather than in metadata. I mean, if in ebuilds, that's > just one more line to write and i know i will do it when i feel > the info from use.desc are not enough/relevant/meaningful. But if > in metadata.xml, i probably won't, i don't even have a single > metadata.xml file in my overlays (why should i btw?). > > Another argument is that this USE flags descriptions would often > be relevant only for a few versions of the package (I'm thinking > of messages like "Support for libfoo is still a bit experimental, > so use this flag with care. Libbar is still prefered."). Adding > that in metadata.xml would require some kind of per-version tags, > that start to be a bit complex... And I think that for devs, it > would be rather natural to add that kind of temporary notes in > ebuilds (they currently use shell comments anyway), but easy to > forget if in a separate file. > > Maybe that's worth a gentoo-dev@ discussion? After all, it's not > just about portage code. > > > Direct portage support is not needed. > > Hmm, maybe yes. I would not be against an "emerge -p -vv" mode > which would display this USE flag desriptions (not the standard > ones sure, only the ones redefined per-package). That sounds like > the easier way to know that some of them are highly encouraged, or > discouraged, or a bit different from what they mean in general, > etc. > --
signature.asc
Description: This is a digitally signed message part
