From: "Kent Fredric" <kentfredric@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] automated extended information gathering
Date: Sun, 8 Jul 2007 17:12:45 +1200 [thread overview]
Message-ID: <8cd1ed20707072212o61ee7014gee5a6e5c503c0535@mail.gmail.com> (raw)
In-Reply-To: <200707080101.53131.vapier@gentoo.org>
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
next prev parent reply other threads:[~2007-07-08 5:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-07 21:43 [gentoo-dev] automated extended information gathering Mike Frysinger
2007-07-07 22:58 ` Petteri Räty
2007-07-07 23:10 ` Marius Mauch
2007-07-07 23:24 ` Kevin Lacquement
2007-07-07 23:41 ` Mike Frysinger
2007-07-08 0:21 ` [gentoo-dev] " Duncan
2007-07-08 0:52 ` [gentoo-dev] " Kent Fredric
2007-07-08 3:19 ` Mike Frysinger
2007-07-08 3:31 ` Kent Fredric
2007-07-08 3:56 ` Mike Frysinger
2007-07-08 4:42 ` Kent Fredric
2007-07-08 5:01 ` Mike Frysinger
2007-07-08 5:12 ` Kent Fredric [this message]
2007-07-08 11:04 ` [gentoo-dev] " Steve Long
2007-07-08 10:45 ` [gentoo-dev] " Mike Auty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8cd1ed20707072212o61ee7014gee5a6e5c503c0535@mail.gmail.com \
--to=kentfredric@gmail.com \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox