| 1 |
>>I thought of a command like emerge mozilla-firefox --useinfo |
| 2 |
>>that prints what each flag is good for. Maybe some are explained in 5 |
| 3 |
>>words, other may need 5 lines. |
| 4 |
>> |
| 5 |
>> |
| 6 |
> |
| 7 |
>Personally, I think that this has only become necessary because USE flags are |
| 8 |
>overloaded too much and usually encompass an unintuitive set of |
| 9 |
>functionality. In other words, I think the flaw is with the USE flags that |
| 10 |
>have been created rather than the USE system itself. |
| 11 |
> |
| 12 |
>Take the USE flag "perl", for example. It has the description "Adds |
| 13 |
>support/bindings for the Perl language." but for mysql setting it enables the |
| 14 |
>installation of some support scripts that just happen to be written in perl. |
| 15 |
> |
| 16 |
>I'd be much more inclined to push for making the USE flags themselves more |
| 17 |
>intuitive rather than adding another layer of documentation to exlain the |
| 18 |
>unintuitiveness (which would likely be poorly written anyway). |
| 19 |
> |
| 20 |
> |
| 21 |
You say it has become necessary... wow... |
| 22 |
If you think a special flag has a bad name, just tell the ebuild |
| 23 |
maintainers to rename it. They will do. Sure. Just as i always get |
| 24 |
positve feedback when i make a request for enhancement... |
| 25 |
Renaming would cause new trouble, i guess you know that better than me. |
| 26 |
|
| 27 |
But even if your flag was named "usefulperlplugins" it would not say all |
| 28 |
that could be said about it. |
| 29 |
When you told me about "--changelog" i just wondered you didn't tell me |
| 30 |
to rtfm. |
| 31 |
man emerge provides information on possible options, why should there |
| 32 |
not be a way to get information on an ebuilds option??? |
| 33 |
|
| 34 |
The useflag "xprint" sounds like printing support, but doesn't tell if |
| 35 |
you need it if you use cups or the kde-printing system or... whatever. |
| 36 |
|
| 37 |
> |
| 38 |
>HOWTOs can usually be found by navigating from the package's home page. |
| 39 |
>If not, a quick google will find any that exist. |
| 40 |
> |
| 41 |
> |
| 42 |
- There are many Gentoo-related HOWTOs, not linked on a projects homepage |
| 43 |
- Some ebuilds give homepages like "gnome.org" just for some little |
| 44 |
gnome app that is not linked on gnome.org |
| 45 |
- There are not only howtos but other useful related pages |
| 46 |
|
| 47 |
Maybe 9000 ebuilds will never have HOWTOs linked to them and maybe 50% |
| 48 |
of the users will never use the advanced information. But the others will. |
| 49 |
Why do you think just because YOU don't need it, noone will? |
| 50 |
|
| 51 |
No, don't give information to users! Don't have a defined way to get |
| 52 |
information to a package! It's evil! |
| 53 |
The defined way would be <wiki-URL>/<ebuild> or emerge <ebuild> --help |
| 54 |
or whatever. |
| 55 |
You don't want anything like that and i don't understand that. |
| 56 |
|
| 57 |
>>BTW, if "This is out of the domain of a package in any package |
| 58 |
>>management system", then why do some packages print additional |
| 59 |
>>information after emerging, like what files should be updated manually? |
| 60 |
>> |
| 61 |
>> |
| 62 |
> |
| 63 |
>Usually it's because configuration file layout differs from upstream's |
| 64 |
>defaults or some other Gentoo-specific information. |
| 65 |
> |
| 66 |
> |
| 67 |
That question was rhetorical. Of course it's because portage can't |
| 68 |
handle everything. |
| 69 |
This is why there should be an easy, defined way to get information. |
| 70 |
|
| 71 |
Caliga |
| 72 |
-- |
| 73 |
gentoo-portage-dev@g.o mailing list |
Archives