From: Daniel Stiefelmaier <mail@stiefelweb.de>
To: gentoo-portage-dev@lists.gentoo.org
Subject: Re: [gentoo-portage-dev] Improved user information and communication
Date: Sat, 01 Oct 2005 21:41:05 +0200 [thread overview]
Message-ID: <433EE651.1060403@stiefelweb.de> (raw)
In-Reply-To: <200510020204.01855.jstubbs@gentoo.org>
>>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
next prev parent reply other threads:[~2005-10-01 19:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-01 5:01 [gentoo-portage-dev] Improved user information and communication Daniel Stiefelmaier
2005-10-01 5:17 ` Jason Stubbs
2005-10-01 16:08 ` Daniel Stiefelmaier
2005-10-01 17:04 ` Jason Stubbs
2005-10-01 19:41 ` Daniel Stiefelmaier [this message]
2005-10-01 20:07 ` Simon Stelling
2005-10-01 21:57 ` Daniel Stiefelmaier
2005-10-01 22:25 ` Brian Harring
2005-10-02 2:54 ` Daniel Stiefelmaier
2005-10-02 11:45 ` Simon Stelling
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=433EE651.1060403@stiefelweb.de \
--to=mail@stiefelweb.de \
--cc=gentoo-portage-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox