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

[Brian Harring]

On Sat, Oct 01, 2005 at 11:57:01PM +0200, Daniel Stiefelmaier wrote:
>
> >>man emerge provides information on possible options, why should there
> >>not be a way to get information on an ebuilds option???
> >
> >
> >because emerge is the tool, not the object. You wouldn't expect the
> >openoffice documentation to cover examples for different kinds of
> >letters, would you?
>
> err.. i think you got me wrong... i do not expect emerge to have a
> built-in list of use flags.
> The description should be in the .ebuilds or metadata.xml
> But i hope you do agree, that eix or emerge are the appropriate tools to
> dig such information.

Nope, I don't agree.  

> (maybe eix more than emerge)
> Just like "emerge -vv" will print information about the ebuild
> maintainers in future release, if i got that right.

Lifted from metadata.xml .

Jamming a 'built-in list of use flags' into ebuilds/metadata.xml first 
of all is vague, second of all is going to jack up the tree's size, 
third of all will lead to a buttload of redundant information across 
the tree.

So... nail it down, instead of the vague "eix/emerge should do this".
If you're suggesting it read use.* info from profiles/use.*, state so.

> >>The useflag "xprint" sounds like printing support, but doesn't tell
> >>if you need it if you use cups or the kde-printing system or...
> >>whatever.
> >
> >
> >~ $ grep xprint /usr/portage/profiles/use.desc
> >xprint - Support for xprint, http://www.mozilla.org/projects/xprint/
> >
> >what do you need more?
>
> - ease of use
> - elegance
Eye of the beholder, not an objective point
> - not need to know about every portage file (especially if new to gentoo)
> - time efficiency (for dozens of flags)
for x in flag1 flag2 flag3; do grep /usr/portage/profiles/use.*; done
> - non-global flags
See above.

> eix also provides only information that you could grep in a more or less
> elegant way.
> or using google...

Portage does you mean, since eix is just a tool that read directly 
from portage underlying files (and is going to get boned by portage 
changes to the underlying cache at some point).

Use ufed, is my opinion on this, or write a tool/extension of existing 
tools.


> >>Why do you think just because YOU don't need it, noone will?
> >
> >
> >This is not a personal debate. The most important reason I see against
> >this idea is that portage is a package manager, not a documentation
> >center.

What you're not groking here is that people work on 
A) what they find interesting
B) what they think *needs* to be done.

Via that ordering, the subjective bit you're throwing out is nulled; 
use flag display is minor compared to fixing portage's screwups from 
where I sit.

Additionally turning the question,
Why do you think just because YOU think it's needed, others will?

> most programs, even those for gurus, print information about their
> option or AT LEAST how to GET information. still, these programs are
> "not a documentation center".

This makes no sense.


> >Why should the ebuild contain links to documentation? To be honest,
> >not even the HOMEPAGE info is needed, it's just for the user's
> >convenience.
>
> even emerge is "just for the user's convenience"
> even distributions are "just for the user's convenience", who needs them?
> i never heard someone argueing that a feature is needless because it is
> convenient.
> features are there to be convenient.

Stretching the example to the extreme doesn't prove your point (don't 
do it if you want people to actually respond).


> >I tend to refer to the UNIX principle: The right tool for the right
> >job. For your problem, google (or any other search engine of course)
> >is the right tool.
>
> what should i say? don't you have bookmarks of good sites? do you always
> google for them?
> of course you will get what you want in many cases but not always.
>
> another unix principle is that everybody can do everything the way he
> likes. in this case, i prefer to have a "readers choice" instead of
> googling and digging the perls.

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.


> also, i agree that emerge may not be the right tool for that. may be
> "eix" or a new one.
> what this is about, is including additional information (only one link
> that will not hurt you) in the ebuilds or metadata.xml

Guessing you're not aware of the cache, nor the dtd for metadata.xml
Slapping stuff into the cache requires portage modifications, both for 
the package and for the rsync cache generation.

It can be done, but the question before doing it is exactly what this 
is going to yield, is it really the right route, and what is going to 
be broken by this (since tools *do* read directly from cache entries 
even if it's daft to do so).


> >Do you think we're all sadists?
>
> No, but hard to believe that you are not ignorant against people
> - that like to have features you personally find useless
> - that may be not using linux since 1992 and need more good
> documentation to install and maintain their system
> - that (therefore) do not know the linux/gentoo/portage file structure
> by heart
>
> >Sorry, but such statements don't help your argumentation.
>
> Did you think the statements in Jasons first reply were all helping the
> discussion?

Play nice, or go play somewhere else, bluntly.

You're not convincing anybody that *your* personal opinion of how it 
should be done is the correct way, further you're *not* going to pull 
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).

Others pissing you off is no reason to respond in kind, nor any way to 
get anything productive out of this discussion beyond it descending to 
a flamewar.


> >>BTW, if "This is out of the domain of a package in any package
> >>management system", then why do some packages print additional
> >>information after emerging, like what files should be updated manually?
> >
> >For the user's convenience of course.
>
> This sounds like they are needless.

Eh? 

> >Introducing documentation links in ebuilds  however is a massive
> >effort, and I don't think that effort is worth it. I'd rather fix a
> >broken package than googling for documentation.
>
> I did not yet dive into portage, but why is it such a big effort? For
> the ebuilds themselves it is adding one more line on the next regular
> update. (This would be for the wiki. If the help on the useflags would
> be included in the ebuild and not in the wiki, yes, then it would be a
> bit more effort. But i guess the maintainers know their flags and could
> add some lines that describe them quickly)

I suggest you jump into portage internals.

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.

Not trying to be overly harsh here, but people have pointed out why 
there are issues with it.  Address the issues, don't fall back to 
rhetoric or "it should be".  Check the code, look into it rather then 
telling others they should do it.

my slightly flamey 2 cents.
~harring