1 |
On Fri, 2004-09-03 at 17:15, Jason Stubbs wrote: |
2 |
> On Saturday 04 September 2004 00:10, Eldad Zack wrote: |
3 |
> > On Fri, 2004-09-03 at 08:10, Nicholas Jones wrote: |
4 |
> > > functions.sh (from baselayout) dependence needs to go away. |
5 |
> > > All used functions need to be logged/rewritten to not use those |
6 |
> > > functions, and instead maintain its own. |
7 |
> > |
8 |
> > I propose overriding einfo/... after sourcing functions.sh in ebuild.sh. |
9 |
> No, they really really need to be new commands. A few examples of why: |
10 |
|
11 |
<snip> |
12 |
|
13 |
> This is all stuff that is meaningless if the build succeeds. As far as I know, |
14 |
> einfo and friends were not created for use in ebuilds and just began being |
15 |
> used as it was convenient at the time. |
16 |
|
17 |
My original thought was just that. I wouldn't give a wetslap about some |
18 |
of the einfo's but some of them are really important. |
19 |
I tried per-ebuild logging, but it doesn't cut it (for me) - just too |
20 |
much cruft. I guess I could grep-hack around it... anyway, notices would |
21 |
limit the messages to only the ebuild (and not the entire process). |
22 |
|
23 |
Someone said earlier (Thomas) - "Your solution would require patching |
24 |
hundreds of ebuilds, just to avoid patching portage? Imho, this is a |
25 |
very wrong approach." |
26 |
|
27 |
And it has a good point to it - For users to benefit from this change, |
28 |
all the ebuilds need to me fixed, changing einfo/ewarn/eerror to their |
29 |
new equiv's. |
30 |
|
31 |
> Secondly, overriding is not good either. If you are overriding, it must be |
32 |
> because the functions do different things. If they are doing different |
33 |
> things, why call them the same thing? |
34 |
|
35 |
Not different as such - they do almost the same thing, just that the new |
36 |
functions has an additional side-effect of outputting to a notice file |
37 |
(and without color, so it is logfile friendly) |
38 |
|
39 |
> The code itself is okay, but what functions are required needs to be |
40 |
> discussed, IMO. Then explicit definitions of when each function is used needs |
41 |
> to be given and each ebuild/eclass updated to use them. |
42 |
|
43 |
Well, what are the needs beyond logging? The functionality can be added |
44 |
very simply to this function. Including mailing out and the likes - All |
45 |
the ebuild writer do is exactly what they do now, pass a message out. |
46 |
|
47 |
> If everyone really really disagrees, I guess you can just create one more |
48 |
> function for the meaningless "pretty" stuff that gets outputted by ebuilds |
49 |
> and eclasses and just convert those. However, be aware that you are adding |
50 |
> another burden of backward compatibility that will only slow down portage's |
51 |
> progress further. |
52 |
|
53 |
That would be a very ugly hack (== something you shouldn't add to |
54 |
portage) - It would like wrapping around portage and parsing the |
55 |
per-ebuild logs... or did you mean something else? |
56 |
|
57 |
BTW, anyone who want to test it can look for the ebuild.sh patch in my |
58 |
page (http://dev.gentoo.org/~eldad/). |
59 |
|
60 |
-- |
61 |
|
62 |
Eldad Zack <eldad@g.o> |
63 |
Key/Fingerprint at pgp.mit.edu, ID 0x96EA0A93 |