public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "D. Tuinstra" <tuinstra@inteo.com>
To: gentoo-dev@gentoo.org
Subject: [gentoo-dev] Re: Readme files for portage (was: A nice idea to improve portage)
Date: Wed, 11 Jun 2003 09:24:01 -0400	[thread overview]
Message-ID: <bc7bf2$qef$1@main.gmane.org> (raw)
In-Reply-To: 20030611061056.B1052@datanode.net

Michael Cummings wrote:

> On Wed, Jun 11, 2003 at 11:37:02AM +0100, MooktaKiNG wrote:
>> Another good reason to have a README is becuase sometimes people
>> want to know more about a program. Without having to install it.
>> 
>> If they can learn about the program before they install. They are
>> more aware of how hard/easy the installtion is.
> 
> I thought that was one of the reasons the source URL shows up in a
> search. It's how I've always checked to see what a package does.
> README files, imo, are great in theory but put additional
> maintenance strain on a dev. Just my two euros,
> 
> Mike

As I see the original proposal, it was to give users essential
post-install information regarding any further steps they need to
take. This kind of information is different from pre-emerge info
that a user uses to decide the desirability of a package.

Pre-emerge info
---------------
Still, a small README could be valuable in some situations. For
example: "This package is included in portage for backwards
compatability for systems that have to interoperate with
MegaCruft's General Ledger FPS. If you don't have to do this you
may wish to consider <KDE-alternate> or <GNOME-alternate>. They
provide the same features within a modern UI, don't hog the CPU,
and don't require you to do manual post-emerge steps. And BTW, the
official site is a pathetic mass of marketing-speak, go to the
user-group page at <URL> instead." This shouldn't be too much of a
dev burden if it's optional and intended to communicate info that
wouldn't be found on an official web page.

A pre-emerge README feature runs the risk of encouraging
editorializing (as above :-), but hey, as long as its kept
reasonable that's part of the fun.

Post-emerge info
----------------
I'm all for it. My wish list: append each package's message to a
file named something like "emerge_messages_<timestamp>". These
would be stored in a standard location relative to the user running
emerge. At the end of the emerge, if the file is empty portage
deletes it and no mention is made of it. If the file is nonempty,
portage displays a standard message directing the user to read it.

Two new emerge commands: 'einfomsg' to write a string to the message
file; 'einfocat' to cat a file to it.

Messages written to the file should be no more than ~25 lines of
text each, with some standard header (e.g., line of dashes, ebuild
name, line of dashes). If 25 lines isn't enough room, the message
should direct the user to more instructions in
/usr/share/doc/<package>.

  --Dwight Tuinstra




--
gentoo-dev@gentoo.org mailing list


  parent reply	other threads:[~2003-06-11 14:17 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-10 14:25 [gentoo-dev] ebuild question MAL
2003-06-10 15:40 ` [gentoo-dev] A nice idea to improve portage MooktaKiNG
2003-06-10 16:07   ` Matthew Kennedy
2003-06-10 18:05   ` John Robinson
2003-06-10 20:20     ` Philippe Lafoucrière
2003-06-11  3:18       ` Luke Graham
2003-06-11  5:10         ` Bill Kenworthy
2003-06-10 21:56     ` MooktaKiNG
2003-06-10 21:42       ` Zach Forrest
2003-06-10 23:26         ` Kumba
2003-06-11 11:52   ` [gentoo-dev] Readme files for portage (was: A nice idea to improve portage) Svyatogor
2003-06-11 10:37     ` MooktaKiNG
2003-06-11 10:10       ` Michael Cummings
2003-06-11 10:44         ` Paul de Vrieze
2003-06-11 13:24         ` D. Tuinstra [this message]
2003-06-11 15:47           ` [gentoo-dev] " oford
2003-06-11 17:06         ` [gentoo-dev] " MooktaKiNG
2003-06-12 11:34 ` [gentoo-dev] ebuild question Amiel Martin

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='bc7bf2$qef$1@main.gmane.org' \
    --to=tuinstra@inteo.com \
    --cc=gentoo-dev@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