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

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

[Daniel Stiefelmaier]

Hi!

I'd like to introduce two ideas i had to improve portage.

sometimes i'd like to know something more about a package before i 
emerge it.

1. release notes. (for the ebuild, not the application)
as a release notes file exists, a parameter could be used to show the 
most recent entry.
maybe this fits "eix" better than "emerge"
2. advanced package info
most important here is an explanation of the available use flags. i know 
there is a list of most flags (http://www.gentoo.org/dyn/use-index.xml) 
but it is incomplete and doesnt explain some flags well. some have 
different behaviour in different packages.
some flags are self-explanatory, but some are not. for example, the 
"xprint" comment should say, that this is not necessary to print, and 
under what circumstances it is needed.

also, the advanced could provide
- links to howto's (like configuring apache)
- list packages that are of use for this (plugins or utilized apps like 
cervisia that integrates in quanta plus)
- tell how to contact the ebuild maintainer

that led my to another idea: a wiki for all ebuilds in portage.
all the information could then be in the wiki, and eix/emerge just print 
the wiki-link.
i'd suggest mediawiki, as it has a discussion page attached.
maybe the wiki itself can only be changed by developers, and feedback is 
given on the discussion page.

just some ideas, maybe needing some development, i hope you find them 
useful. :)

greets, Caliga


-- 
gentoo-portage-dev@gentoo.org mailing list

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

[Jason Stubbs]

On Saturday 01 October 2005 14:01, Daniel Stiefelmaier wrote:
> I'd like to introduce two ideas i had to improve portage.

I haven't had an idea introduced to me that was new for at least a year.. 
Patches are more interesting.

> sometimes i'd like to know something more about a package before i
> emerge it.
>
> 1. release notes. (for the ebuild, not the application)
> as a release notes file exists, a parameter could be used to show the
> most recent entry.
> maybe this fits "eix" better than "emerge"

emerge --changelog ?

> 2. advanced package info
> most important here is an explanation of the available use flags. i know
> there is a list of most flags (http://www.gentoo.org/dyn/use-index.xml)
> but it is incomplete and doesnt explain some flags well. some have
> different behaviour in different packages.
> some flags are self-explanatory, but some are not. for example, the
> "xprint" comment should say, that this is not necessary to print, and
> under what circumstances it is needed.

This should go to gentoo-dev@g.o as ebuild developers are the ones that decide 
what USE flags are available and how they're documented.

> also, the advanced could provide
> - links to howto's (like configuring apache)

This is out of the domain of a package in any package management system IMO.

> - list packages that are of use for this (plugins or utilized apps like
> cervisia that integrates in quanta plus)

Do you mean finding packages that depend on that package in question?

> - tell how to contact the ebuild maintainer

metadata.xml. This information is printed out when using -vv in 
portage-2.1_alpha.

> that led my to another idea: a wiki for all ebuilds in portage.
> all the information could then be in the wiki, and eix/emerge just print
> the wiki-link.
> i'd suggest mediawiki, as it has a discussion page attached.
> maybe the wiki itself can only be changed by developers, and feedback is
> given on the discussion page.

Personally, I hate most wikis. 9 times out of 10, they are full of 
half-correct information. This makes them all the more dangerous as the 
"average Joe" can't tell what's correct and what isn't.

> just some ideas, maybe needing some development, i hope you find them
> useful. :)

Ideas are "a dime, a dozen".

--
Jason Stubbs
-- 
gentoo-portage-dev@gentoo.org mailing list

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

[Daniel Stiefelmaier]

>emerge --changelog ?
>  
>
k, sorry :)

>This should go to gentoo-dev@g.o as ebuild developers are the ones that decide 
>what USE flags are available and how they're documented.
>  
>
Of course they decide what flags are available, but how do they decide 
how they are documented? I'm sorry if i did not yet discover gentoos 
ebuild-feature-documentation system.

I thought of a command like emerge mozilla-firefox --useinfo
that prints what each flag is good for. Maybe some are explained in 5 
words, other may need 5 lines.

>>also, the advanced could provide
>>- links to howto's (like configuring apache)
>>    
>>
>
>This is out of the domain of a package in any package management system IMO.
>  
>
You are right, there may be no pms out there that has this feature.
I refuse to accept this as an argument to not change that.
You may be a pro who does not need any HOWTOs, i am not.
Portage saves a lot of work for people who use it. But in some cases, 
ebuilds don't do everything they could or should.
Example: Firefox and Thunderbird don't give a damn on the LANG setting, 
they are english by default. There is no obvious way to change the 
language, you need to do some investigation. (Look for the HOWTO ;) )

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?
THIS is not really the solution. if you batch-emerge or the package that 
wants to tell you something is just a dependancy, then you may probably 
miss that note.

Another reason to inform the user before emerging maybe this:
I emerged a package recently, think it was amule, that first emerged 
some dependancies, including wxGTK.
Then, after all dependancies were emerged, the package itself quitted 
saying that wxGTK needs to be emerged with flag wxgtk1.
I thought the ebuild could manage flags of dependancies automatically, 
but that is not the point.
The user could be informed before starting to emerge.

>>- list packages that are of use for this (plugins or utilized apps like
>>cervisia that integrates in quanta plus)
>>    
>>
>
>Do you mean finding packages that depend on that package in question?
>  
>
Not necessarily. Cervisia, Kompare and Tidy are standalone applications, 
but Quanta integrates them automatically if they are installed.

>>- tell how to contact the ebuild maintainer
>>    
>>
>
>metadata.xml. This information is printed out when using -vv in 
>portage-2.1_alpha.
>  
>
Hey, thats cool :)
But then, why not include additional information there? like the useflag 
documentation or links to HOWTOs?

>Personally, I hate most wikis. 9 times out of 10, they are full of 
>half-correct information. This makes them all the more dangerous as the 
>"average Joe" can't tell what's correct and what isn't.
>  
>
My wiki experiences are all good, but i also wrote, that it could only 
be maintained by the developers. Only the discussion page attached to 
each page is open for comments. This also prevents defacements.

>Ideas are "a dime, a dozen".
>  
>
Ideas are even free. That's what makes open source what it is.
Ask Bryce Harrington what he thinks how Inkscape's well development is 
related to its community.

Caliga
-- 
gentoo-portage-dev@gentoo.org mailing list

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

[Jason Stubbs]

On Sunday 02 October 2005 01:08, Daniel Stiefelmaier wrote:
> On Saturday 01 October 2005 14:17, Jason Stubbs wrote:
> >This should go to gentoo-dev@g.o as ebuild developers are the ones that
> > decide what USE flags are available and how they're documented.
>
> Of course they decide what flags are available, but how do they decide
> how they are documented? I'm sorry if i did not yet discover gentoos
> ebuild-feature-documentation system.

I meant the actual strings themselves. However, any change that affects or 
enables work for ebuild devs really needs to be discussed with them.

> I thought of a command like emerge mozilla-firefox --useinfo
> that prints what each flag is good for. Maybe some are explained in 5
> words, other may need 5 lines.

Personally, I think that this has only become necessary because USE flags are 
overloaded too much and usually encompass an unintuitive set of 
functionality. In other words, I think the flaw is with the USE flags that 
have been created rather than the USE system itself.

Take the USE flag "perl", for example. It has the description "Adds 
support/bindings for the Perl language." but for mysql setting it enables the 
installation of some support scripts that just happen to be written in perl.

I'd be much more inclined to push for making the USE flags themselves more 
intuitive rather than adding another layer of documentation to exlain the 
unintuitiveness (which would likely be poorly written anyway).

> >>also, the advanced could provide
> >>- links to howto's (like configuring apache)
> >
> >This is out of the domain of a package in any package management system
> > IMO.
>
> You are right, there may be no pms out there that has this feature.
> I refuse to accept this as an argument to not change that.
> You may be a pro who does not need any HOWTOs, i am not.

HOWTOs can usually be found by navigating from the package's home page.
If not, a quick google will find any that exist.

> Portage saves a lot of work for people who use it. But in some cases,
> ebuilds don't do everything they could or should.

If ebuilds aren't doing what they could or should be, you can open specific 
bugs regarding those packages.

> 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?

Usually it's because configuration file layout differs from upstream's 
defaults or some other Gentoo-specific information.

> THIS is not really the solution. if you batch-emerge or the package that
> wants to tell you something is just a dependancy, then you may probably
> miss that note.

http://bugs.gentoo.org/show_bug.cgi?id=11359

> Another reason to inform the user before emerging maybe this:
> I emerged a package recently, think it was amule, that first emerged
> some dependancies, including wxGTK.
> Then, after all dependancies were emerged, the package itself quitted
> saying that wxGTK needs to be emerged with flag wxgtk1.
> I thought the ebuild could manage flags of dependancies automatically,
> but that is not the point.
> The user could be informed before starting to emerge.

http://bugs.gentoo.org/show_bug.cgi?id=2272

> >>- list packages that are of use for this (plugins or utilized apps like
> >>cervisia that integrates in quanta plus)
> >
> >Do you mean finding packages that depend on that package in question?
>
> Not necessarily. Cervisia, Kompare and Tidy are standalone applications,
> but Quanta integrates them automatically if they are installed.

A "related" field? Could be useful. This is also a point for discussion on 
gentoo-dev@g.o though.

> >Personally, I hate most wikis. 9 times out of 10, they are full of
> >half-correct information. This makes them all the more dangerous as the
> >"average Joe" can't tell what's correct and what isn't.
>
> My wiki experiences are all good, but i also wrote, that it could only
> be maintained by the developers. Only the discussion page attached to
> each page is open for comments. This also prevents defacements.

More work for ebuild devs, then. Guess where this discussion should be? ;)

--
Jason Stubbs
-- 
gentoo-portage-dev@gentoo.org mailing list

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

[Daniel Stiefelmaier]

>>I thought of a command like emerge mozilla-firefox --useinfo
>>that prints what each flag is good for. Maybe some are explained in 5
>>words, other may need 5 lines.
>>    
>>
>
>Personally, I think that this has only become necessary because USE flags are 
>overloaded too much and usually encompass an unintuitive set of 
>functionality. In other words, I think the flaw is with the USE flags that 
>have been created rather than the USE system itself.
>
>Take the USE flag "perl", for example. It has the description "Adds 
>support/bindings for the Perl language." but for mysql setting it enables the 
>installation of some support scripts that just happen to be written in perl.
>
>I'd be much more inclined to push for making the USE flags themselves more 
>intuitive rather than adding another layer of documentation to exlain the 
>unintuitiveness (which would likely be poorly written anyway).
>  
>
You say it has become necessary... wow...
If you think a special flag has a bad name, just tell the ebuild 
maintainers to rename it. They will do. Sure. Just as i always get 
positve feedback when i make a request for enhancement...
Renaming would cause new trouble, i guess you know that better than me.

But even if your flag was named "usefulperlplugins" it would not say all 
that could be said about it.
When you told me about "--changelog" i just wondered you didn't tell me 
to rtfm.
man emerge provides information on possible options, why should there 
not be a way to get information on an ebuilds option???

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.

>
>HOWTOs can usually be found by navigating from the package's home page.
>If not, a quick google will find any that exist.
>  
>
- There are many Gentoo-related HOWTOs, not linked on a projects homepage
- Some ebuilds give homepages like "gnome.org" just for some little 
gnome app that is not linked on gnome.org
- There are not only howtos but other useful related pages

Maybe 9000 ebuilds will never have HOWTOs linked to them and maybe 50% 
of the users will never use the advanced information. But the others will.
Why do you think just because YOU don't need it, noone will?

No, don't give information to users! Don't have a defined way to get 
information to a package! It's evil!
The defined way would be <wiki-URL>/<ebuild> or emerge <ebuild> --help 
or whatever.
You don't want anything like that and i don't understand that.

>>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?
>>    
>>
>
>Usually it's because configuration file layout differs from upstream's 
>defaults or some other Gentoo-specific information.
>  
>
That question was rhetorical. Of course it's because portage can't 
handle everything.
This is why there should be an easy, defined way to get information.

Caliga
-- 
gentoo-portage-dev@gentoo.org mailing list

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

[Simon Stelling]

Hi,

Daniel Stiefelmaier wrote:
>> Take the USE flag "perl", for example. It has the description "Adds 
>> support/bindings for the Perl language." but for mysql setting it 
>> enables the installation of some support scripts that just happen to 
>> be written in perl.

Since perl is a global use flag, this is inappropriate use. You might want to 
file a bug :)

> 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?

> 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?

> - There are many Gentoo-related HOWTOs, not linked on a projects homepage

You can easily find those through searching google

> - Some ebuilds give homepages like "gnome.org" just for some little 
> gnome app that is not linked on gnome.org

Same here, googling usually helps

> - There are not only howtos but other useful related pages

Same here.

> 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.

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. 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.

> No, don't give information to users! Don't have a defined way to get 
> information to a package! It's evil!

Do you think we're all sadists? Sorry, but such statements don't help your 
argumentation.

>>> 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. 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'm sure every user is able to search for HOWTOs, but not every user is able to 
fix a broken package himself.

> That question was rhetorical. Of course it's because portage can't 
> handle everything.
> This is why there should be an easy, defined way to get information.

This defined way is google, IMHO.

Regards,

-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
-- 
gentoo-portage-dev@gentoo.org mailing list

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

[Daniel Stiefelmaier]

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

>> 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
- not need to know about every portage file (especially if new to gentoo)
- time efficiency (for dozens of flags)
- non-global flags

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


>> 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.

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".

> 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.

> 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.

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

> 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?

>> 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.

> 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)

>> That question was rhetorical. Of course it's because portage can't 
>> handle everything.
>> This is why there should be an easy, defined way to get information.
>
>
> This defined way is google, IMHO.

IMHO it is a helpshift

Caliga
-- 
gentoo-portage-dev@gentoo.org mailing list

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

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 7581 bytes --]

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


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

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

[Simon Stelling]

Daniel Stiefelmaier wrote:
> 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"

Why do you need a new funky tool called einfo when 'cat' already exists? XML is 
such a great format because it is readable for humans, not because it is just 
sexy ;)

>> 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.

Sure, but some people here know much more than you and me about portage's 
internals, and so they know whether something works or not, and what the 
problems might be. Instead of feeling ignored you should probably try to 
understand WHY people think it's not a good idea.

> i did not yet get constructive feedback and i don't know portage and its 
> developers well enough to make a pleasing plan.

That's probably the biggest issue. You don't know portage well enough to make a 
pleasing plan, but you ask people who didn't asked for your feature to make one. 
I hope you got the 'free' in 'free software' the right way.

> 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.

I hate to tell people, but I have to: please, RTFM. use.local.desc is mentioned 
on line 60 of 'man portage' and it is explained briefly later on, additionally, 
the handbook even shows a snipplet from use.desc in 'Working with Gentoo -> USE 
flags', so one should think that users actually READ documentation carefully. 
Documentation is there to be read and understood, not to be ignored.
At least I wondered why you wanted to add so much redundant data to the tree, as 
it was absolutely evident to me that use.[local.]desc exists and that you know 
of it too.

> Well, that's fine. :)
> Just that some flags could be explained more comprehensive, not only 
> telling the obvious.

That's surely something that could be improved, but you have to explain which 
descriptions you find not helpful. A list would be very useful.

> Now i understand Jason and agree, that missused global flags should be 
> renamed. (but still believe there is a small chance they will)

File a bug for every package, wait some time, and if the maintainer refuses and 
you still think the use flags violate the policy, involve QA.

> 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?

wrong.

Friendly regards,

-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
-- 
gentoo-portage-dev@gentoo.org mailing list