| 1 |
>> man emerge provides information on possible options, why should there |
| 2 |
>> not be a way to get information on an ebuilds option??? |
| 3 |
> |
| 4 |
> |
| 5 |
> because emerge is the tool, not the object. You wouldn't expect the |
| 6 |
> openoffice documentation to cover examples for different kinds of |
| 7 |
> letters, would you? |
| 8 |
|
| 9 |
err.. i think you got me wrong... i do not expect emerge to have a |
| 10 |
built-in list of use flags. |
| 11 |
The description should be in the .ebuilds or metadata.xml |
| 12 |
But i hope you do agree, that eix or emerge are the appropriate tools to |
| 13 |
dig such information. |
| 14 |
(maybe eix more than emerge) |
| 15 |
Just like "emerge -vv" will print information about the ebuild |
| 16 |
maintainers in future release, if i got that right. |
| 17 |
|
| 18 |
>> The useflag "xprint" sounds like printing support, but doesn't tell |
| 19 |
>> if you need it if you use cups or the kde-printing system or... |
| 20 |
>> whatever. |
| 21 |
> |
| 22 |
> |
| 23 |
> ~ $ grep xprint /usr/portage/profiles/use.desc |
| 24 |
> xprint - Support for xprint, http://www.mozilla.org/projects/xprint/ |
| 25 |
> |
| 26 |
> what do you need more? |
| 27 |
|
| 28 |
- ease of use |
| 29 |
- elegance |
| 30 |
- not need to know about every portage file (especially if new to gentoo) |
| 31 |
- time efficiency (for dozens of flags) |
| 32 |
- non-global flags |
| 33 |
|
| 34 |
eix also provides only information that you could grep in a more or less |
| 35 |
elegant way. |
| 36 |
or using google... |
| 37 |
|
| 38 |
|
| 39 |
>> Why do you think just because YOU don't need it, noone will? |
| 40 |
> |
| 41 |
> |
| 42 |
> This is not a personal debate. The most important reason I see against |
| 43 |
> this idea is that portage is a package manager, not a documentation |
| 44 |
> center. |
| 45 |
|
| 46 |
most programs, even those for gurus, print information about their |
| 47 |
option or AT LEAST how to GET information. still, these programs are |
| 48 |
"not a documentation center". |
| 49 |
|
| 50 |
> Why should the ebuild contain links to documentation? To be honest, |
| 51 |
> not even the HOMEPAGE info is needed, it's just for the user's |
| 52 |
> convenience. |
| 53 |
|
| 54 |
even emerge is "just for the user's convenience" |
| 55 |
even distributions are "just for the user's convenience", who needs them? |
| 56 |
i never heard someone argueing that a feature is needless because it is |
| 57 |
convenient. |
| 58 |
features are there to be convenient. |
| 59 |
|
| 60 |
> I tend to refer to the UNIX principle: The right tool for the right |
| 61 |
> job. For your problem, google (or any other search engine of course) |
| 62 |
> is the right tool. |
| 63 |
|
| 64 |
what should i say? don't you have bookmarks of good sites? do you always |
| 65 |
google for them? |
| 66 |
of course you will get what you want in many cases but not always. |
| 67 |
|
| 68 |
another unix principle is that everybody can do everything the way he |
| 69 |
likes. in this case, i prefer to have a "readers choice" instead of |
| 70 |
googling and digging the perls. |
| 71 |
|
| 72 |
also, i agree that emerge may not be the right tool for that. may be |
| 73 |
"eix" or a new one. |
| 74 |
what this is about, is including additional information (only one link |
| 75 |
that will not hurt you) in the ebuilds or metadata.xml |
| 76 |
|
| 77 |
> Do you think we're all sadists? |
| 78 |
|
| 79 |
No, but hard to believe that you are not ignorant against people |
| 80 |
- that like to have features you personally find useless |
| 81 |
- that may be not using linux since 1992 and need more good |
| 82 |
documentation to install and maintain their system |
| 83 |
- that (therefore) do not know the linux/gentoo/portage file structure |
| 84 |
by heart |
| 85 |
|
| 86 |
> Sorry, but such statements don't help your argumentation. |
| 87 |
|
| 88 |
Did you think the statements in Jasons first reply were all helping the |
| 89 |
discussion? |
| 90 |
|
| 91 |
>> BTW, if "This is out of the domain of a package in any package |
| 92 |
>> management system", then why do some packages print additional |
| 93 |
>> information after emerging, like what files should be updated manually? |
| 94 |
> |
| 95 |
> For the user's convenience of course. |
| 96 |
|
| 97 |
This sounds like they are needless. |
| 98 |
|
| 99 |
> Introducing documentation links in ebuilds however is a massive |
| 100 |
> effort, and I don't think that effort is worth it. I'd rather fix a |
| 101 |
> broken package than googling for documentation. |
| 102 |
|
| 103 |
I did not yet dive into portage, but why is it such a big effort? For |
| 104 |
the ebuilds themselves it is adding one more line on the next regular |
| 105 |
update. (This would be for the wiki. If the help on the useflags would |
| 106 |
be included in the ebuild and not in the wiki, yes, then it would be a |
| 107 |
bit more effort. But i guess the maintainers know their flags and could |
| 108 |
add some lines that describe them quickly) |
| 109 |
|
| 110 |
>> That question was rhetorical. Of course it's because portage can't |
| 111 |
>> handle everything. |
| 112 |
>> This is why there should be an easy, defined way to get information. |
| 113 |
> |
| 114 |
> |
| 115 |
> This defined way is google, IMHO. |
| 116 |
|
| 117 |
IMHO it is a helpshift |
| 118 |
|
| 119 |
Caliga |
| 120 |
-- |
| 121 |
gentoo-portage-dev@g.o mailing list |
Archives