From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23800 invoked from network); 3 Sep 2004 05:10:36 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 3 Sep 2004 05:10:36 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1C36LL-0007mz-Jw for arch-gentoo-dev@lists.gentoo.org; Fri, 03 Sep 2004 05:10:35 +0000 Received: (qmail 15788 invoked by uid 89); 3 Sep 2004 05:10:35 +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 30374 invoked from network); 3 Sep 2004 05:10:34 +0000 Date: Fri, 3 Sep 2004 01:10:38 -0400 From: Nicholas Jones Cc: gentoo-dev Message-ID: <20040903051038.GA11426@twobit.net> References: <1094155935.19504.40.camel@localhost> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <1094155935.19504.40.camel@localhost> User-Agent: Mutt/1.5.6i Subject: [gentoo-dev] Package notices X-Archives-Salt: 17810932-0fd1-4d6c-a683-8a4ae6e7db0b X-Archives-Hash: 1c7cca9588ac95b7cb59e0829c131de1 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Basically, it could be implemented using a new eclass or just adding the > enotice function to eutils - I wouldn't want all the einfos logged, > anyway. (patching notices? no thanks.) > What I would like, would be messages from packages like cacti. > enotice itself will write into the file and emit an einfo. I mentioned what I would consider most acceptable at some point, but no one appears to have seen that, so it must have gotten lost. He's what needs to get done for this to work: functions.sh (from baselayout) dependence needs to go away. All used functions need to be logged/rewritten to not use those functions, and instead maintain its own. All said functions must be rewritten, for portage, with the capability to handle colors and terminals and the like as portage does currently. (People don't want ANSI in their logs.) The output can be writting in any number of ways to a file in ${T} during the execution of the build. This does not violate sandbox and is quite easy to find. PORTAGE can then manipulate the log, perform notifications, and do whatever else is necessary to maintain that file around cleanings and other merges. ${T}/notices.${PF}.${TYPE} would be perfectly fine as long as it was definitive/unique to the particular package. Notices of all types could also simply be prefixed. '*' '-' '!' or whatever seems best. If you are so inclined, you could also write a parser for these files that can designate priorities using color or some other visual aid. (Keep in mind that it must be deterministic through simple ascii as well for synthesisers.) For multiple reasons, I prefer python for these tools. There are many, many possibilities, but please follow the outline provided here. --NJ --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBN/zOBDOEqLMd+jQRAj8/AJwJmHP9D7w0iNGLotBx9P1igQZ8ZwCfYL28 /W8OBSM2JRMLRIpmBVy0Fmo= =vOPV -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI--