Gentoo Archives: gentoo-dev

From: Eldad Zack <eldad@g.o>
To: Jason Stubbs <jstubbs@g.o>, Gentoo-Dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] Package notices
Date: Fri, 03 Sep 2004 14:44:12
Message-Id: 1094228112.7077.33.camel@localhost
In Reply to: Re: [gentoo-dev] Package notices by Jason Stubbs
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

Attachments

File name MIME type
signature.asc application/pgp-signature