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@gentoo.org mailing list
