1 |
> Basically, it could be implemented using a new eclass or just adding the |
2 |
> enotice function to eutils - I wouldn't want all the einfos logged, |
3 |
> anyway. (patching notices? no thanks.) |
4 |
|
5 |
> What I would like, would be messages from packages like cacti. |
6 |
> enotice itself will write into the file and emit an einfo. |
7 |
|
8 |
I mentioned what I would consider most acceptable at some point, |
9 |
but no one appears to have seen that, so it must have gotten lost. |
10 |
|
11 |
He's what needs to get done for this to work: |
12 |
|
13 |
functions.sh (from baselayout) dependence needs to go away. |
14 |
All used functions need to be logged/rewritten to not use those |
15 |
functions, and instead maintain its own. |
16 |
|
17 |
All said functions must be rewritten, for portage, with the |
18 |
capability to handle colors and terminals and the like as |
19 |
portage does currently. (People don't want ANSI in their logs.) |
20 |
|
21 |
The output can be writting in any number of ways to a file in |
22 |
${T} during the execution of the build. This does not violate |
23 |
sandbox and is quite easy to find. |
24 |
|
25 |
PORTAGE can then manipulate the log, perform notifications, |
26 |
and do whatever else is necessary to maintain that file around |
27 |
cleanings and other merges. |
28 |
|
29 |
${T}/notices.${PF}.${TYPE} |
30 |
would be perfectly fine as long as it was definitive/unique |
31 |
to the particular package. Notices of all types could also |
32 |
simply be prefixed. '*' '-' '!' or whatever seems best. |
33 |
|
34 |
If you are so inclined, you could also write a parser for |
35 |
these files that can designate priorities using color or |
36 |
some other visual aid. (Keep in mind that it must be |
37 |
deterministic through simple ascii as well for synthesisers.) |
38 |
For multiple reasons, I prefer python for these tools. |
39 |
|
40 |
There are many, many possibilities, but please follow |
41 |
the outline provided here. |
42 |
|
43 |
--NJ |