On 7/8/07, Mike Frysinger <[EMAIL PROTECTED]> wrote:
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 ?
Ok, I've re-thought some of my ideas and tried to come up with a more
concise explanation
with some practical example syntax. The basic concept of 'check' was
'this will work even if the package aint installed yet' and info was
'for working but bust packages only', but that can be superceded with
a CHECKLIST and a conditional driven INFO function.
CHECKLIST="
a? ( some-cat/a-lib )
b? ( some-cat/b-lib )
"
That would make building a checklist for lazy people as simple as
CHECKLIST="${RDEPEND}"
pkg_getinfo(){
if [[ installed ]]; then
someSelfCheck;
someSelfCheck;
echo someversionNumberStuff;
fi
someBasicSystemCheckRequiredForPkgToWork();
if [[ someCondition ]]; then
get_info( some-cat/d-lib ); # its not on the dep list, but we want
to check its info status as part of /our/ info status.
fi
}
in this case:
emerge --info Pkg
--> pkg_getinfo();
--> foreach( $ChecklistItem )
----> pkg_getinfo()
That way if somethings installed but merely bust, you get all the
useful information,
and if it wont install, you still get the useful information as to why
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
--
Kent
ruby -e '[1, 2, 4, 7, 0, 9, 5, 8, 3, 10, 11, 6, 12, 13].each{|x|
print "enNOSPicAMreil [EMAIL PROTECTED]"[(2*x)..(2*x+1)]}'
--
[EMAIL PROTECTED] mailing list
