Re: [gentoo-portage-dev] Improved user information and communication

[Daniel Stiefelmaier]

>Jamming a 'built-in list of use flags' into ebuilds/metadata.xml first
>of all is vague,
>
I tried to explain simon that i don't want to have the explanations 
built into the emerge-programm, because i thought he understood me that way.

> second of all is going to jack up the tree's size,
>
>
i dont believe that as i'd guess only the most common ebuilds would have 
it added in the near future. also it seems to me that the changelog 
files take way the most place.
I already said, that it might be satisfying to only include a wiki-link.
A new tool, lets say einfo, that prints info from metadata.xml. The link 
could be read from metadata.xml or, if desired, generated automatiacally 
in the form "http://gentoo-wiki.com/Ebuild:www-client/mozilla-firefox"

>third of all will lead to a buttload of redundant information across
>the tree.
>
>
global use flag definitions could still be used, but optionally 
overwritten with local ones in the ebuilds.

>So... nail it down, instead of the vague "eix/emerge should do this".
>
>
im getting vague because if i am precise, everybody just tells me that 
it will not work that way.
i did not yet get constructive feedback and i don't know portage and its 
developers well enough to make a pleasing plan.

>If you're suggesting it read use.* info from profiles/use.*, state so.
>
>
To be honest i just discovered use.local.desc, i didn't know this 
already exists. (only use.desc) Sorry for my lack of knowledge. 
Constructive feedback would have been to tell me the information i want 
already exists. Nobody wondered, why i want to add information to 
ebuilds that already exists.

Well, that's fine. :)
Just that some flags could be explained more comprehensive, not only 
telling the obvious.
Now i understand Jason and agree, that missused global flags should be 
renamed. (but still believe there is a small chance they will)

>Use ufed, is my opinion on this, or write a tool/extension of existing
>tools.
>
>
Now that i know that all the needed metadata already exists, i can :)

>You've got the unix principle slightly wrong there- implicit is that
>if no alternative exists, the person persuing the alternative
>*implements* it themselves rather then riding others to do it.
>
>
all the responses i got were so declining that i thought
"even if you would code it, we will never include it, even if you'll 
edit all the 10k metadata.xml files, we just don't WANT it, it's useless 
for us and everybody else"
wrong conclusion?

>You're not convincing anybody that *your* personal opinion of how it
>should be done is the correct way,
>
it wasn't on my mind to say *how* it should be done. but all replies 
just were saying it should be done at all, it's useless, senseless, to 
much work...

>that off if you're being agressive/insulting about it (I'll give you
>the benfit of the doubt and assume you're not intentionally trying to
>insult people).
>
>
Thanks. I'd say it was more of a desperate sigh. Sarcastic i have to 
admit. ;)

>Additionally... you're proposing a retrofit of metadata into the entire
>tree, which is a *lot* of work (that's fact), leaving the question of
>what really is gained, if there was a better way, etc.
>
>
I expected to hear the better way from the experienced. Maybe you are 
the one who finally pointed me to it, indirectly :)

greets,
Caliga
-- 
gentoo-portage-dev@g.o mailing list