On Saturday 07 July 2007, Kent Fredric wrote: > On 7/8/07, Mike Frysinger <[EMAIL PROTECTED]> 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
signature.asc
Description: This is a digitally signed message part.
