1 |
On Saturday 04 September 2004 00:10, Eldad Zack wrote: |
2 |
> On Fri, 2004-09-03 at 08:10, Nicholas Jones wrote: |
3 |
> > functions.sh (from baselayout) dependence needs to go away. |
4 |
> > All used functions need to be logged/rewritten to not use those |
5 |
> > functions, and instead maintain its own. |
6 |
> |
7 |
> I propose overriding einfo/... after sourcing functions.sh in ebuild.sh. |
8 |
|
9 |
No, they really really need to be new commands. A few examples of why: |
10 |
|
11 |
eutils.eclass: einfo "Applying various patches (bugfixes/updates)..." |
12 |
eutils.eclass: einfo "${EPATCH_SINGLE_MSG}" |
13 |
eutils.eclass: einfo "Applying ${x##*/}..." |
14 |
virtualx.eclass: einfo "Scanning for a open DISPLAY to start Xvfb..." |
15 |
|
16 |
mjpegtools/mjpegtools-1.6.0-r7.ebuild: einfo "Building mjpegtools" |
17 |
drip/drip-0.9.0_alpha3.ebuild: einfo "Rerunnig autoconf/automake..." |
18 |
mplayer/mplayer-1.0_pre3-r5.ebuild: einfo "Make" |
19 |
mplayer/mplayer-1.0_pre3-r5.ebuild: einfo "Make completed" |
20 |
mplayer/mplayer-1.0_pre3-r5.ebuild: einfo "Make install" |
21 |
mplayer/mplayer-1.0_pre3-r5.ebuild: einfo "Make install completed" |
22 |
|
23 |
This is all stuff that is meaningless if the build succeeds. As far as I know, |
24 |
einfo and friends were not created for use in ebuilds and just began being |
25 |
used as it was convenient at the time. |
26 |
|
27 |
Secondly, overriding is not good either. If you are overriding, it must be |
28 |
because the functions do different things. If they are doing different |
29 |
things, why call them the same thing? |
30 |
|
31 |
> > All said functions must be rewritten, for portage, with the |
32 |
> > capability to handle colors and terminals and the like as |
33 |
> > portage does currently. (People don't want ANSI in their logs.) |
34 |
> |
35 |
> Logfiles are handled seperately while screen output uses ANSI. |
36 |
> If portage could relay the color decision onwards to bash, it would |
37 |
> take only a small change to enforce that. |
38 |
> |
39 |
> > ${T}/notices.${PF}.${TYPE} |
40 |
> |
41 |
> I'd rather use a single file - notices.${PF} as the code shows: |
42 |
> (should be inserted in ebuild.sh after functions.sh is sourced) |
43 |
> |
44 |
> ### Code start ### |
45 |
> |
46 |
> einfo() { |
47 |
> enotice info "${*}" |
48 |
> } |
49 |
> |
50 |
> ewarn() { |
51 |
> enotice warn "${*}" |
52 |
> } |
53 |
> |
54 |
> eerror() |
55 |
> { |
56 |
> enotice error "${*}" |
57 |
> } |
58 |
> |
59 |
> enotice() |
60 |
> { |
61 |
> local color |
62 |
> local type |
63 |
> |
64 |
> type="${1}" |
65 |
> |
66 |
> case "${type}" in |
67 |
> "info") |
68 |
> color="${GOOD}" |
69 |
> ;; |
70 |
> "warn") |
71 |
> color="${WARN}" |
72 |
> ;; |
73 |
> "error") |
74 |
> color="${BAD}" |
75 |
> ;; |
76 |
> esac |
77 |
> |
78 |
> shift |
79 |
> |
80 |
> echo "[${type}] ${*}" >> ${T}/notices.${PF} |
81 |
> echo " ${color}*${NORMAL} ${*}" |
82 |
> |
83 |
> } |
84 |
> |
85 |
> ### Code End ### |
86 |
> |
87 |
> You can also merge the notice file into the package inself: |
88 |
> (inside dyn_install, just after calling src_install) |
89 |
> |
90 |
> #enotice |
91 |
> if [ -n ${PORT_ENOTICE_DIR} && -r ${T}/notices.${PF} ] |
92 |
> then |
93 |
> install -d ${D}${PORT_ENOTICE_DIR} |
94 |
> cp ${T}/notices.${PF} ${D}${PORT_ENOTICE_DIR} |
95 |
> fi |
96 |
> |
97 |
> or any other way you think is best. |
98 |
> |
99 |
> If this is acceptable, I can write a matching notice reader. |
100 |
|
101 |
The code itself is okay, but what functions are required needs to be |
102 |
discussed, IMO. Then explicit definitions of when each function is used needs |
103 |
to be given and each ebuild/eclass updated to use them. |
104 |
|
105 |
If everyone really really disagrees, I guess you can just create one more |
106 |
function for the meaningless "pretty" stuff that gets outputted by ebuilds |
107 |
and eclasses and just convert those. However, be aware that you are adding |
108 |
another burden of backward compatibility that will only slow down portage's |
109 |
progress further. |
110 |
|
111 |
Regards, |
112 |
Jason Stubbs |
113 |
|
114 |
-- |
115 |
gentoo-dev@g.o mailing list |