From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30800 invoked by uid 1002); 11 Jun 2003 15:54:41 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 16955 invoked from network); 11 Jun 2003 15:54:41 -0000 From: oford To: "D. Tuinstra" Cc: gentoo-dev In-Reply-To: References: <20030611115214.4b3e2552.svyatogor@gentoo.org> <1109.10.0.0.1.1055327822.squirrel@mooktaking.homeip.net> <20030611061056.B1052@datanode.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-e9XaETbrNIpr0om2Snd8" Organization: Message-Id: <1055346460.29520.7.camel@spider.hotmonkeyporn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4- Date: 11 Jun 2003 10:47:40 -0500 Subject: Re: [gentoo-dev] Re: Readme files for portage (was: A nice idea to improve portage) X-Archives-Salt: 92fcc25f-3246-435f-a762-5de272517eaa X-Archives-Hash: a247da1261da4f08f9de07e7614c3547 --=-e9XaETbrNIpr0om2Snd8 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2003-06-11 at 08:24, D. Tuinstra wrote: > Michael Cummings wrote: >=20 > > 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. > >>=20 > >> If they can learn about the program before they install. They are > >> more aware of how hard/easy the installtion is. > >=20 > > 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, > >=20 > > Mike >=20 > 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. >=20 > 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 or . 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 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. >=20 > 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. >=20 > Post-emerge info > ---------------- > I'm all for it. My wish list: append each package's message to a > file named something like "emerge_messages_". 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. >=20 > Two new emerge commands: 'einfomsg' to write a string to the message > file; 'einfocat' to cat a file to it. >=20 > 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/. It should also state which ebuild it belongs to in a very prominent place. I know it sounds obvious but that kind of detail is important :) --=20 Owen Ford --=-e9XaETbrNIpr0om2Snd8 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA+508c7BqG9qbphc4RAiZNAKDjxzVy/p1gIy8TPj7uPP6EbSr5gwCgiarE qMSlmYCTq/rFZ595oPfR21s= =pIjL -----END PGP SIGNATURE----- --=-e9XaETbrNIpr0om2Snd8--