Re: [gentoo-dev] automated extended information gathering

[Mike Frysinger]

On Saturday 07 July 2007, Kent Fredric wrote:
> On 7/8/07, Mike Frysinger <vapier@g.o> wrote:
> > On Saturday 07 July 2007, Kent Fredric wrote:
> > > Implementation details wise, I would like to see packages have
> > > possibly 2 functions,
> > > 1: Info, and 2: Check.
> > > Reason Being that you wont be able to fetch installation status info
> > > on a package thats not installed, and if a package is failing to
> > > install, you're more likely wanting to check the status of the things
> > > it depends on, not the package itself.
> >
> > i dont really understand what you're going for here ... the point was to
> > get extended information on things that are installed ... i dont know
> > what you'd want/expect for trying to query packages that arent installed
> >
> > > Check would contain manual tests for a given package, thats either
> > > installed or not installed ,as well as names of packages to run info
> > > on.
> > >
> > > Info would be more usefull in diagnosing mis-installed packages or
> > > packages that failed to run properly despite being compiled and
> > > installed without a hitch ( it happens )
> >
> > sounds like you're duplicating the point of src_test() but without any
> > real way of quantifying it or making it useful to coordinate things ...
> > please expound on what you're going for because i'm just not seeing it
> > ...
>
> 50% of bugs I tend to see are compile failures.
>
> Compile Failures are often a result of things that the compile was
> dependant on.
>
> Thus, finding info on a given package to understand what its problem
> is, you should be info-querying its dependants, not the package
> itself, no?
>
> Information you want sent to bug reports are related to the software
> that it depended on, no? ( ie: xine-libs wont compile : emerge --info
> xine-libs should report information on ffmpeg, which has changed,
> causing the failure )
>
> And if xine libs wasnt installed, it would be pointless to report
> information about xine-libs installation when its not installed
> becasue it cant be ;)
>
> So instead of asking the user what version of X dependant they have,
> emerge --info atom  should report that in a standardised way, making
> them able to provide more relevant information in the initial report

so you're asking for `emerge --info <atom>` to walk the dependency tree and 
include --info for all things that <atom> depends on ?  how is this relevant 
to the check() function you proposed ?

you are trying to install package X which depends on package Y which is 
broken ... i dont think it's possible/feasible to have ebuilds try and 
diagnosis itself automatically to figure out *how* exactly package Y is 
broken ... if it were possible, we'd be able to write self-healing ebuilds
-mike