| 1 |
On Sunday 08 July 2007, Kent Fredric wrote: |
| 2 |
> Ok, I've re-thought some of my ideas and tried to come up with a more |
| 3 |
> concise explanation |
| 4 |
> with some practical example syntax. The basic concept of 'check' was |
| 5 |
> 'this will work even if the package aint installed yet' and info was |
| 6 |
> 'for working but bust packages only', but that can be superceded with |
| 7 |
> a CHECKLIST and a conditional driven INFO function. |
| 8 |
|
| 9 |
as they say, the devil is in the details ... |
| 10 |
|
| 11 |
> pkg_getinfo(){ |
| 12 |
> if [[ installed ]]; then |
| 13 |
> someSelfCheck; |
| 14 |
> someSelfCheck; |
| 15 |
> echo someversionNumberStuff; |
| 16 |
> fi |
| 17 |
> someBasicSystemCheckRequiredForPkgToWork(); |
| 18 |
> if [[ someCondition ]]; then |
| 19 |
> get_info( some-cat/d-lib ); # its not on the dep list, but we want |
| 20 |
> to check its info status as part of /our/ info status. |
| 21 |
> fi |
| 22 |
> } |
| 23 |
|
| 24 |
the claim i'm making is that there generally isnt any code/checks worth adding |
| 25 |
to ebuilds that would be useful for the purpose of an ebuild diagnosing |
| 26 |
itself to determine whether it is broken and how it is broken. we just dont |
| 27 |
have a language yet to properly describe the process of diagnosing and fixing |
| 28 |
oneself. a fun thesis for an AI doctorate :p |
| 29 |
-mike |
Archives