1 |
On 7/8/07, Mike Frysinger <vapier@g.o> wrote: |
2 |
> On Saturday 07 July 2007, Kent Fredric wrote: |
3 |
> > On 7/8/07, Mike Frysinger <vapier@g.o> wrote: |
4 |
> > > On Saturday 07 July 2007, Kent Fredric wrote: |
5 |
> > > > Implementation details wise, I would like to see packages have |
6 |
> > > > possibly 2 functions, |
7 |
> > > > 1: Info, and 2: Check. |
8 |
> > > > Reason Being that you wont be able to fetch installation status info |
9 |
> > > > on a package thats not installed, and if a package is failing to |
10 |
> > > > install, you're more likely wanting to check the status of the things |
11 |
> > > > it depends on, not the package itself. |
12 |
> > > |
13 |
> > > i dont really understand what you're going for here ... the point was to |
14 |
> > > get extended information on things that are installed ... i dont know |
15 |
> > > what you'd want/expect for trying to query packages that arent installed |
16 |
> > > |
17 |
> > > > Check would contain manual tests for a given package, thats either |
18 |
> > > > installed or not installed ,as well as names of packages to run info |
19 |
> > > > on. |
20 |
> > > > |
21 |
> > > > Info would be more usefull in diagnosing mis-installed packages or |
22 |
> > > > packages that failed to run properly despite being compiled and |
23 |
> > > > installed without a hitch ( it happens ) |
24 |
> > > |
25 |
> > > sounds like you're duplicating the point of src_test() but without any |
26 |
> > > real way of quantifying it or making it useful to coordinate things ... |
27 |
> > > please expound on what you're going for because i'm just not seeing it |
28 |
> > > ... |
29 |
> > |
30 |
> > 50% of bugs I tend to see are compile failures. |
31 |
> > |
32 |
> > Compile Failures are often a result of things that the compile was |
33 |
> > dependant on. |
34 |
> > |
35 |
> > Thus, finding info on a given package to understand what its problem |
36 |
> > is, you should be info-querying its dependants, not the package |
37 |
> > itself, no? |
38 |
> > |
39 |
> > Information you want sent to bug reports are related to the software |
40 |
> > that it depended on, no? ( ie: xine-libs wont compile : emerge --info |
41 |
> > xine-libs should report information on ffmpeg, which has changed, |
42 |
> > causing the failure ) |
43 |
> > |
44 |
> > And if xine libs wasnt installed, it would be pointless to report |
45 |
> > information about xine-libs installation when its not installed |
46 |
> > becasue it cant be ;) |
47 |
> > |
48 |
> > So instead of asking the user what version of X dependant they have, |
49 |
> > emerge --info atom should report that in a standardised way, making |
50 |
> > them able to provide more relevant information in the initial report |
51 |
> |
52 |
> so you're asking for `emerge --info <atom>` to walk the dependency tree and |
53 |
> include --info for all things that <atom> depends on ? how is this relevant |
54 |
> to the check() function you proposed ? |
55 |
|
56 |
Ok, I've re-thought some of my ideas and tried to come up with a more |
57 |
concise explanation |
58 |
with some practical example syntax. The basic concept of 'check' was |
59 |
'this will work even if the package aint installed yet' and info was |
60 |
'for working but bust packages only', but that can be superceded with |
61 |
a CHECKLIST and a conditional driven INFO function. |
62 |
|
63 |
|
64 |
|
65 |
CHECKLIST=" |
66 |
a? ( some-cat/a-lib ) |
67 |
b? ( some-cat/b-lib ) |
68 |
" |
69 |
|
70 |
That would make building a checklist for lazy people as simple as |
71 |
|
72 |
CHECKLIST="${RDEPEND}" |
73 |
|
74 |
|
75 |
pkg_getinfo(){ |
76 |
if [[ installed ]]; then |
77 |
someSelfCheck; |
78 |
someSelfCheck; |
79 |
echo someversionNumberStuff; |
80 |
fi |
81 |
someBasicSystemCheckRequiredForPkgToWork(); |
82 |
if [[ someCondition ]]; then |
83 |
get_info( some-cat/d-lib ); # its not on the dep list, but we want |
84 |
to check its info status as part of /our/ info status. |
85 |
fi |
86 |
} |
87 |
|
88 |
in this case: |
89 |
emerge --info Pkg |
90 |
--> pkg_getinfo(); |
91 |
--> foreach( $ChecklistItem ) |
92 |
----> pkg_getinfo() |
93 |
|
94 |
That way if somethings installed but merely bust, you get all the |
95 |
useful information, |
96 |
and if it wont install, you still get the useful information as to why |
97 |
|
98 |
|
99 |
> you are trying to install package X which depends on package Y which is |
100 |
> broken ... i dont think it's possible/feasible to have ebuilds try and |
101 |
> diagnosis itself automatically to figure out *how* exactly package Y is |
102 |
> broken ... if it were possible, we'd be able to write self-healing ebuilds |
103 |
> -mike |
104 |
> |
105 |
> |
106 |
|
107 |
|
108 |
-- |
109 |
Kent |
110 |
ruby -e '[1, 2, 4, 7, 0, 9, 5, 8, 3, 10, 11, 6, 12, 13].each{|x| |
111 |
print "enNOSPicAMreil kdrtf@×××.com"[(2*x)..(2*x+1)]}' |
112 |
-- |
113 |
gentoo-dev@g.o mailing list |