From: Jason Stubbs <jstubbs@gentoo.org>
To: gentoo-portage-dev@lists.gentoo.org
Subject: Re: [gentoo-portage-dev] Improved user information and communication
Date: Sat, 1 Oct 2005 14:17:28 +0900 [thread overview]
Message-ID: <200510011417.28373.jstubbs@gentoo.org> (raw)
In-Reply-To: <433E1846.1090106@stiefelweb.de>
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
next prev parent reply other threads:[~2005-10-01 5: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 [this message]
2005-10-01 16:08 ` Daniel Stiefelmaier
2005-10-01 17:04 ` Jason Stubbs
2005-10-01 19:41 ` Daniel Stiefelmaier
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=200510011417.28373.jstubbs@gentoo.org \
--to=jstubbs@gentoo.org \
--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