1 |
Pieter, |
2 |
|
3 |
Imagine the expert system is 'screen' or interacts similarly to it, meaning |
4 |
it can read all output from portage and it can send a command line back (i.e. |
5 |
emulate a real user). This would basically put the system out of portage so |
6 |
why make it a requirement? So that during development it can be accounted for |
7 |
that some things will want unfiltered output and input. Maybe I'm not making |
8 |
myself clear again so let me know if you still don't see what I mean now. |
9 |
|
10 |
I would in no way expect portage to deliver the expert system but it should |
11 |
IMHO provide the frame on which one could be built. |
12 |
|
13 |
Bart |
14 |
|
15 |
> > 8. have hooks for an expert system that can deal with compile errors |
16 |
> |
17 |
> This request is too abstract. This could become very interesting in |
18 |
> combination with the freshmeat sync feature that was requested on -dev |
19 |
> earlier. This is why I like looking at ebuild in a directory as a |
20 |
> knowledge base (KB): |
21 |
> there are learning techniques which can be used to , based on 'past' |
22 |
> knowledge, provide about-data (dependency info, features, ...) for a |
23 |
> newer version. The problem however is the howtodata (some patches might |
24 |
> no longer apply, ...) it would be nice to have a reasoning system for |
25 |
> that too, but I think this falls outside the scope of the current |
26 |
> effort. |
27 |
|
28 |
|
29 |
-- |
30 |
gentoo-portage-dev@g.o mailing list |