Re: [gentoo-dev] Package notices

[Jason Stubbs <jstubbs@gentoo.org>]

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