From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10989 invoked from network); 3 Sep 2004 14:12:28 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 3 Sep 2004 14:12:28 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1C3Enk-0005wy-15 for arch-gentoo-dev@lists.gentoo.org; Fri, 03 Sep 2004 14:12:28 +0000 Received: (qmail 32516 invoked by uid 89); 3 Sep 2004 14:12:27 +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 12541 invoked from network); 3 Sep 2004 14:12:26 +0000 From: Jason Stubbs To: gentoo-dev@lists.gentoo.org Date: Fri, 3 Sep 2004 23:15:05 +0900 User-Agent: KMail/1.7 References: <1094155935.19504.40.camel@localhost> <20040903051038.GA11426@twobit.net> <1094224207.7076.9.camel@localhost> In-Reply-To: <1094224207.7076.9.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409032315.05479.jstubbs@gentoo.org> Subject: Re: [gentoo-dev] Package notices X-Archives-Salt: a485d73a-d758-42e8-ad7e-9261ffdd5fb0 X-Archives-Hash: 871e34a8039f3b7e87f87fdb1a35be82 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: eutils.eclass: einfo "Applying various patches (bugfixes/updates)..." eutils.eclass: einfo "${EPATCH_SINGLE_MSG}" eutils.eclass: einfo "Applying ${x##*/}..." virtualx.eclass: einfo "Scanning for a open DISPLAY to start Xvfb..." mjpegtools/mjpegtools-1.6.0-r7.ebuild: einfo "Building mjpegtools" drip/drip-0.9.0_alpha3.ebuild: einfo "Rerunnig autoconf/automake..." mplayer/mplayer-1.0_pre3-r5.ebuild: einfo "Make" mplayer/mplayer-1.0_pre3-r5.ebuild: einfo "Make completed" mplayer/mplayer-1.0_pre3-r5.ebuild: einfo "Make install" mplayer/mplayer-1.0_pre3-r5.ebuild: einfo "Make install completed" This is all stuff that is meaningless if the build succeeds. As far as I know, einfo and friends were not created for use in ebuilds and just began being used as it was convenient at the time. Secondly, overriding is not good either. If you are overriding, it must be because the functions do different things. If they are doing different things, why call them the same thing? > > 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.) > > Logfiles are handled seperately while screen output uses ANSI. > If portage could relay the color decision onwards to bash, it would > take only a small change to enforce that. > > > ${T}/notices.${PF}.${TYPE} > > I'd rather use a single file - notices.${PF} as the code shows: > (should be inserted in ebuild.sh after functions.sh is sourced) > > ### Code start ### > > einfo() { > enotice info "${*}" > } > > ewarn() { > enotice warn "${*}" > } > > eerror() > { > enotice error "${*}" > } > > enotice() > { > local color > local type > > type="${1}" > > case "${type}" in > "info") > color="${GOOD}" > ;; > "warn") > color="${WARN}" > ;; > "error") > color="${BAD}" > ;; > esac > > shift > > echo "[${type}] ${*}" >> ${T}/notices.${PF} > echo " ${color}*${NORMAL} ${*}" > > } > > ### Code End ### > > You can also merge the notice file into the package inself: > (inside dyn_install, just after calling src_install) > > #enotice > if [ -n ${PORT_ENOTICE_DIR} && -r ${T}/notices.${PF} ] > then > install -d ${D}${PORT_ENOTICE_DIR} > cp ${T}/notices.${PF} ${D}${PORT_ENOTICE_DIR} > fi > > or any other way you think is best. > > If this is acceptable, I can write a matching notice reader. The code itself is okay, but what functions are required needs to be discussed, IMO. Then explicit definitions of when each function is used needs to be given and each ebuild/eclass updated to use them. If everyone really really disagrees, I guess you can just create one more function for the meaningless "pretty" stuff that gets outputted by ebuilds and eclasses and just convert those. However, be aware that you are adding another burden of backward compatibility that will only slow down portage's progress further. Regards, Jason Stubbs -- gentoo-dev@gentoo.org mailing list