From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-dev-return-15497-arch-gentoo-dev=gentoo.org@lists.gentoo.org> Received: (qmail 16369 invoked from network); 3 Sep 2004 14:44:12 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 3 Sep 2004 14:44:12 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1C3FIS-0004BQ-HW for arch-gentoo-dev@lists.gentoo.org; Fri, 03 Sep 2004 14:44:12 +0000 Received: (qmail 26138 invoked by uid 89); 3 Sep 2004 14:44:12 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: <mailto:gentoo-dev@gentoo.org> List-Help: <mailto:gentoo-dev-help@gentoo.org> List-Unsubscribe: <mailto:gentoo-dev-unsubscribe@gentoo.org> List-Subscribe: <mailto:gentoo-dev-subscribe@gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 7076 invoked from network); 3 Sep 2004 14:44:11 +0000 From: Eldad Zack <eldad@gentoo.org> To: Jason Stubbs <jstubbs@gentoo.org>, Gentoo-Dev <gentoo-dev@lists.gentoo.org> In-Reply-To: <200409032315.05479.jstubbs@gentoo.org> References: <1094155935.19504.40.camel@localhost> <20040903051038.GA11426@twobit.net> <1094224207.7076.9.camel@localhost> <200409032315.05479.jstubbs@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-QKV3HtIXPX8Cr/aNpI2M" Message-Id: <1094228112.7077.33.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 03 Sep 2004 19:15:12 +0300 Subject: Re: [gentoo-dev] Package notices X-Archives-Salt: 13a9e1f7-9eec-4454-8fbd-97061e8dd2bd X-Archives-Hash: dec06c9a229d51604b827e270ef94f86 --=-QKV3HtIXPX8Cr/aNpI2M Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-09-03 at 17:15, Jason Stubbs wrote: > On Saturday 04 September 2004 00:10, Eldad Zack wrote: > > On Fri, 2004-09-03 at 08:10, Nicholas Jones wrote: > > > 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. > > > > I propose overriding einfo/... after sourcing functions.sh in ebuild.sh= . > No, they really really need to be new commands. A few examples of why: <snip> > This is all stuff that is meaningless if the build succeeds. As far as I = know,=20 > einfo and friends were not created for use in ebuilds and just began bein= g=20 > used as it was convenient at the time. My original thought was just that. I wouldn't give a wetslap about some of the einfo's but some of them are really important. I tried per-ebuild logging, but it doesn't cut it (for me) - just too much cruft. I guess I could grep-hack around it... anyway, notices would limit the messages to only the ebuild (and not the entire process). Someone said earlier (Thomas) - "Your solution would require patching hundreds of ebuilds, just to avoid patching portage? Imho, this is a very wrong approach." And it has a good point to it - For users to benefit from this change, all the ebuilds need to me fixed, changing einfo/ewarn/eerror to their new equiv's. > Secondly, overriding is not good either. If you are overriding, it must b= e=20 > because the functions do different things. If they are doing different=20 > things, why call them the same thing?=20 Not different as such - they do almost the same thing, just that the new functions has an additional side-effect of outputting to a notice file (and without color, so it is logfile friendly) > The code itself is okay, but what functions are required needs to be=20 > discussed, IMO. Then explicit definitions of when each function is used n= eeds=20 > to be given and each ebuild/eclass updated to use them. Well, what are the needs beyond logging? The functionality can be added very simply to this function. Including mailing out and the likes - All the ebuild writer do is exactly what they do now, pass a message out. > If everyone really really disagrees, I guess you can just create one more= =20 > function for the meaningless "pretty" stuff that gets outputted by ebuild= s=20 > and eclasses and just convert those. However, be aware that you are addin= g=20 > another burden of backward compatibility that will only slow down portage= 's=20 > progress further. That would be a very ugly hack (=3D=3D something you shouldn't add to portage) - It would like wrapping around portage and parsing the per-ebuild logs... or did you mean something else? BTW, anyone who want to test it can look for the ebuild.sh patch in my page (http://dev.gentoo.org/~eldad/). --=20 Eldad Zack <eldad@gentoo.org> Key/Fingerprint at pgp.mit.edu, ID 0x96EA0A93 --=-QKV3HtIXPX8Cr/aNpI2M Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBBOJiPT+MN7JbqCpMRAll5AJ9Ljuh1PBqlHFdsvC0e3838E5Y4fACeK434 ox2vpBFl6l5zsKVktpUyQSU= =v6NZ -----END PGP SIGNATURE----- --=-QKV3HtIXPX8Cr/aNpI2M--