[gentoo-dev] automated extended information gathering

[gentoo-dev] automated extended information gathering

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 519 bytes --]

often times when i get a bug report about certain packages, there's 
information about that package that i usually ask for ... i wonder if this 
can be automated

perhaps extend the syntax of profiles/info_pkgs:
<atom> [command to pass to system()]
sys-libs/glibc /lib/libc.so.6

then when people run `emerge --verbose --info`, for every atom matched as 
installed, it'd automatically run the listed command and display the output

useful ?  security issue waiting to explode ?  crazy wacky monkey ?
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] automated extended information gathering

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 692 bytes --]

Mike Frysinger kirjoitti:
> often times when i get a bug report about certain packages, there's 
> information about that package that i usually ask for ... i wonder if this 
> can be automated
> 
> perhaps extend the syntax of profiles/info_pkgs:
> <atom> [command to pass to system()]
> sys-libs/glibc /lib/libc.so.6
> 
> then when people run `emerge --verbose --info`, for every atom matched as 
> installed, it'd automatically run the listed command and display the output
> 
> useful ?  security issue waiting to explode ?  crazy wacky monkey ?
> -mike

Or a new bug wizard that gives you a list of packages and and asks extra
info based on that.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] automated extended information gathering

[Marius Mauch]

On Sat, 7 Jul 2007 17:43:44 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> often times when i get a bug report about certain packages, there's 
> information about that package that i usually ask for ... i wonder if
> this can be automated
> 
> perhaps extend the syntax of profiles/info_pkgs:
> <atom> [command to pass to system()]
> sys-libs/glibc /lib/libc.so.6
> 
> then when people run `emerge --verbose --info`, for every atom
> matched as installed, it'd automatically run the listed command and
> display the output
> 
> useful ?  security issue waiting to explode ?  crazy wacky monkey ?

I see several problems with that approach:
1) adding a secondary purpose to info_pkgs, history has shown that we
should avoid such things (think packages file)
2) as a consequence of 1), I assume people would add packages to
info_pkgs only for the new purpose, cluttering regular --info output
with irrelevant information
3) sounds more like something that should only trigger in `emerge
--info foo`
4) likely not backwards compatible
5) considering 3), I'd rather see such information be specified by
ebuilds somehow, not a global file (think about overlays). Maybe by
installing a script in a specific location or so.

Marius

-- 
Marius Mauch <genone@gentoo.org>
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] automated extended information gathering

[Kevin Lacquement]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marius Mauch wrote:
>
> 5) considering 3), I'd rather see such information be specified by
> ebuilds somehow, not a global file (think about overlays). Maybe by
> installing a script in a specific location or so.
>
> Marius
How about adding another function to the ebuild format?  pkg_getinfo()?

Kevin


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGkCDCr4p8oOjnnKARAojFAJ0duN7Ur5wmf8e770AztJip7nxPngCgg5yH
Fqtd2iL+ourVZM+uMTP9SMY=
=ShqV
-----END PGP SIGNATURE-----

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] automated extended information gathering

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 384 bytes --]

On Saturday 07 July 2007, Kevin Lacquement wrote:
> Marius Mauch wrote:
> > 5) considering 3), I'd rather see such information be specified by
> > ebuilds somehow, not a global file (think about overlays). Maybe by
> > installing a script in a specific location or so.
>
> How about adding another function to the ebuild format?  pkg_getinfo()?

that trumps everything i got ;)
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

[gentoo-dev] Re: automated extended information gathering

[Duncan]

Mike Frysinger <vapier@gentoo.org> posted
200707071941.38300.vapier@gentoo.org, excerpted below, on  Sat, 07 Jul
2007 19:41:37 -0400:

> On Saturday 07 July 2007, Kevin Lacquement wrote:
>>
>> How about adding another function to the ebuild format?  pkg_getinfo()?
> 
> that trumps everything i got ;)

It's pretty intuitive as well.  So much so that on initial read, that's 
what I thought you were suggesting originally.  

Should be pretty easy for users to figure out, and it could be mentioned 
(as is emerge --info) right in bugzilla, too.  I'd suggest a bugzy bug to 
that effect as soon as the feature is in portage.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] automated extended information gathering

[Kent Fredric]

On 7/8/07, Kevin Lacquement <kevin@lacqui.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Marius Mauch wrote:
> >
> > 5) considering 3), I'd rather see such information be specified by
> > ebuilds somehow, not a global file (think about overlays). Maybe by
> > installing a script in a specific location or so.
> >
> > Marius
> How about adding another function to the ebuild format?  pkg_getinfo()?
>
> Kevin
>
>

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.

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 )

( These could even be good enough to help the user self-diagnose the
problem, a feature I consider wonderfully intuitive and not in any
other distribution yet ;) )

pkg_check()
{
            if ( uses blah )
            {
                 some_basic_check();
                 pkg_getinfo_installed( x11-wm/blah );
            }

}


I may be on to a good thing, I may  be retarded, but I'd rather
provide something that could be a potentially good thing with the risk
of being retarded than to have hidden that good thing. ;)


-- 
Kent
ruby -e '[1, 2, 4, 7, 0, 9, 5, 8, 3, 10, 11, 6, 12, 13].each{|x|
print "enNOSPicAMreil kdrtf@gma.com"[(2*x)..(2*x+1)]}'
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] automated extended information gathering

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]

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 ...
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] automated extended information gathering

[Kent Fredric]

On 7/8/07, Mike Frysinger <vapier@gentoo.org> 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 ...
> -mike
>
>

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

-- 
Kent
ruby -e '[1, 2, 4, 7, 0, 9, 5, 8, 3, 10, 11, 6, 12, 13].each{|x|
print "enNOSPicAMreil kdrtf@gma.com"[(2*x)..(2*x+1)]}'
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] automated extended information gathering

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 2830 bytes --]

On Saturday 07 July 2007, Kent Fredric wrote:
> On 7/8/07, Mike Frysinger <vapier@gentoo.org> 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] automated extended information gathering

[Kent Fredric]

On 7/8/07, Mike Frysinger <vapier@gentoo.org> wrote:
> On Saturday 07 July 2007, Kent Fredric wrote:
> > On 7/8/07, Mike Frysinger <vapier@gentoo.org> 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 kdrtf@gma.com"[(2*x)..(2*x+1)]}'
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] automated extended information gathering

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]

On Sunday 08 July 2007, Kent Fredric wrote:
> 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.

as they say, the devil is in the details ...

> 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
> }

the claim i'm making is that there generally isnt any code/checks worth adding 
to ebuilds that would be useful for the purpose of an ebuild diagnosing 
itself to determine whether it is broken and how it is broken.  we just dont 
have a language yet to properly describe the process of diagnosing and fixing 
oneself.  a fun thesis for an AI doctorate :p
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] automated extended information gathering

[Kent Fredric]

On 7/8/07, Mike Frysinger <vapier@gentoo.org> wrote:
> On Sunday 08 July 2007, Kent Fredric wrote:
> > 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.
>
> as they say, the devil is in the details ...
>
> > 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
> > }
>
> the claim i'm making is that there generally isnt any code/checks worth adding
> to ebuilds that would be useful for the purpose of an ebuild diagnosing
> itself to determine whether it is broken and how it is broken.  we just dont
> have a language yet to properly describe the process of diagnosing and fixing
> oneself.  a fun thesis for an AI doctorate :p
> -mike
>


On 7/8/07, Mike Frysinger <vapier@gentoo.org> wrote:
> often times when i get a bug report about certain packages, there's
> information about that package that i usually ask for ... i wonder if this
> can be automated

The idea was to place the code to provide that information into the
applications pkg_getinfo() section, nothing major, just version
numbers etc, and possibly code to test for scenarios that are known to
exist but theres currently no known way to fix them.

Some of these basic checks can be as simple as grabbing the files
CONTENTS out of edb, and checking all the files listed in it exist,
and are of the right type ( cat CONTENTS | tr "\n" "\0" | xargs -iSTR
-0 file STR ), and arn't symlinks that don't go anywhere, you know,
the usual sort of bugs that flare up as a result of user interaction
;))

The output of those checks are still going to be want to be read and
interpreted by a human, but the more you know of a situation, the more
you have to find the bug with.

-- 
Kent
ruby -e '[1, 2, 4, 7, 0, 9, 5, 8, 3, 10, 11, 6, 12, 13].each{|x|
print "enNOSPicAMreil kdrtf@gma.com"[(2*x)..(2*x+1)]}'
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: automated extended information gathering

[Steve Long]

Kent Fredric wrote:
> On 7/8/07, Mike Frysinger <vapier@gentoo.org> wrote:
>> often times when i get a bug report about certain packages, there's
>> information about that package that i usually ask for ... i wonder if
>> this can be automated

>> > 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
>> > }
>>
Sorry to have skipped the rest of this fascinating discussion, but all I
want to know is does the above fulfil the original criteria? I'm guessing
it does, since the pkgInfo() function ``trumped it all."

>> > 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.
>>
hmm sounds a bit complex to me. "Abstract designs are simple." <tuomov>

But hey, there appear to be loads of 3 line functions all over the shop..

>> the claim i'm making is that there generally isnt any code/checks worth
>> adding to ebuilds that would be useful for the purpose of an ebuild

I think the intent was for the maintainer to decide what to put there?

>> diagnosing
>> itself to determine whether it is broken and how it is broken.  we just
>> dont have a language yet to properly describe the process of diagnosing
>> and fixing
>> oneself.  a fun thesis for an AI doctorate :p

Er no a fun project for a noob programmer in a VVHLL. An interesting project
would be to make a semantic map of all the terms you guys have finally
settled on for the portage API, and then tie that into linguistic analysis
(and perhaps even consider i18n for portCore?) all that other stuff you
were thinking of, yadda yadda. Have you got a PhD yet? ;P

/me runs to pub





Er ofc it's not my trademark... *sheesh*. But I'll claim it if you lot don't
hurry up.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] automated extended information gathering

[Mike Auty]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kent Fredric wrote:
> 
> 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}"
> 

This seems to be quite a heavy solution just to get a little more
information.  Info seems much more simple and flexible.  If you're
having to encode information in the ebuild about "what dependencies to
check when you break" then how will you diagnose missing dependencies?
  From Mike's idea, I envisaged something more along the lines of:

Bug:
"Compilation failed as followed:

  Package X failed to install
  ...stuff...
  X.c: ../Y.h not found
  X.c: ../Z.h not found
  ...stuff..."

Response:
"Could you please run emerge --info --verbose Y Z and paste the output here"

Counter-Response:
" Lots of useful standard info
  Y was compiled with USE flags blah
  Y was compiled from overlay BLAH
  Y's manifest was not signed
  Y's internal env included myconf='--disable-something-critical'
  Z wasn't emerged"

Speedy response:
"Ah, your problem is that for some reason, something-critical was
disabled in package Y, and Z wasn't included in the dependencies.
Please try this to solve it..."

It's difficult to think of situations where you'd ask for information
from an uninstalled ebuild that you couldn't ask for from installed
dependencies, but I'd rather do that manually than try encoding it into
the ebuilds and then still have to ask the user to do it manually in
some circumstances.

Most of this could be in a default pkg_info, but it allows for
overriding by an eclass, and on a per package basis, without requiring
each package writing custom error-locating code.  This is, after all,
just giving more information, it's not guaranteed to find the error.

I hope that makes some sense?

Mike  5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (GNU/Linux)

iD8DBQFGkMBIu7rWomwgFXoRAghUAJ0a/EP6wRQlT2j+GcND5LZoNoqWMwCbBhbR
WwvnMHqEgmlz/auL00YvhIQ=
=kmNa
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list