1 |
On Friday 03 September 2004 23:00, Pablo Villalba wrote: |
2 |
> We're trying to build the house without having the plans for it yet. |
3 |
> What do we need to do here? Which kind of output would be useful? Imho |
4 |
> maintaining regular output (maybe flushing it at the end of all the emerge |
5 |
> process) AND logging it to some special logfile (errors being notices to |
6 |
> syslog too) would do it. |
7 |
> Once this is clear and agreed we could think of how we'd have to implement |
8 |
> it. |
9 |
|
10 |
Nick layed out half the plan already, although it may not have seemed like it |
11 |
- he's very curt but it's usually enough if you know the context. |
12 |
|
13 |
On Friday 03 September 2004 14:10, Nicholas Jones wrote: |
14 |
> He's what needs to get done for this to work: |
15 |
> |
16 |
> functions.sh (from baselayout) dependence needs to go away. |
17 |
> All used functions need to be logged/rewritten to not use those |
18 |
> functions, and instead maintain its own. |
19 |
|
20 |
This must happen so that there is absolutely no (chance of) effect on starting |
21 |
up messages that happen when starting and stopping daemons. Currently, the |
22 |
same functions are used for output. |
23 |
|
24 |
> All said functions must be rewritten, for portage, with the |
25 |
> capability to handle colors and terminals and the like as |
26 |
> portage does currently. (People don't want ANSI in their logs.) |
27 |
|
28 |
Portage has the ability to enable/disable colour based on the terminal type |
29 |
and user's preference. Furthermore, if the output is being logged as well as |
30 |
going to screen, coloured and non-coloured versions of the output must be |
31 |
providable on demand. |
32 |
|
33 |
> The output can be writting in any number of ways to a file in |
34 |
> ${T} during the execution of the build. This does not violate |
35 |
> sandbox and is quite easy to find. |
36 |
|
37 |
This is a simple design descision that fits in well with portage's current |
38 |
security model for merges. |
39 |
|
40 |
> PORTAGE can then manipulate the log, perform notifications, |
41 |
> and do whatever else is necessary to maintain that file around |
42 |
> cleanings and other merges. |
43 |
|
44 |
In other words, any processing done on the logs once they're written must be |
45 |
completely separate from the logging itself. |
46 |
|
47 |
> ${T}/notices.${PF}.${TYPE} |
48 |
> would be perfectly fine as long as it was definitive/unique |
49 |
> to the particular package. Notices of all types could also |
50 |
> simply be prefixed. '*' '-' '!' or whatever seems best. |
51 |
> |
52 |
> If you are so inclined, you could also write a parser for |
53 |
> these files that can designate priorities using color or |
54 |
> some other visual aid. (Keep in mind that it must be |
55 |
> deterministic through simple ascii as well for synthesisers.) |
56 |
> For multiple reasons, I prefer python for these tools. |
57 |
> |
58 |
> There are many, many possibilities, but please follow |
59 |
> the outline provided here. |
60 |
|
61 |
These just show further design possibilities within the above rules but it is |
62 |
open to whomever decides to implement it on the exact details. |
63 |
|
64 |
Regards, |
65 |
Jason Stubbs |
66 |
|
67 |
-- |
68 |
gentoo-dev@g.o mailing list |