From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.62) (envelope-from ) id 1I7OeO-0007TV-GR for garchives@archives.gentoo.org; Sun, 08 Jul 2007 04:45:37 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l684ieQY020698; Sun, 8 Jul 2007 04:44:40 GMT Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l684gn0I018487 for ; Sun, 8 Jul 2007 04:42:49 GMT Received: by py-out-1112.google.com with SMTP id d32so1423266pye for ; Sat, 07 Jul 2007 21:42:49 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=g1TcLjp1Kb6KDnERv1oqkcxXVztstW91LomgIlyCVaEAbQtE9qjT7s9yfzaIIJHpMPlzr4O/vcXSxtzKhdkIt13fgk0GYZcwlfLyj2rpofq9ded42UQp8dX7vi84f0KngzG0pHCaJ/nNdH8NpAxd7+UCqA6EvnFmXFAOaHIh7ew= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fCFN2PFqDhKEEdPEglbo6S6qj4XiKmjr550/kKn3cbB8VfGpQKfed76tzQzHLOfpHjStpO3v9h0shwRDvBRbAygdMPf7KZD6gGUTdJLqDLbkGw0/14N/P/px6akqdSX5yMIYWMhEcs+yk14CuMFDRK7KSQKTd4yqFCB5Kk7Z7g0= Received: by 10.65.72.7 with SMTP id z7mr934850qbk.1183869769313; Sat, 07 Jul 2007 21:42:49 -0700 (PDT) Received: by 10.64.251.15 with HTTP; Sat, 7 Jul 2007 21:42:49 -0700 (PDT) Message-ID: <8cd1ed20707072142y7c029135y6aef76aaee7ae2f3@mail.gmail.com> Date: Sun, 8 Jul 2007 16:42:49 +1200 From: "Kent Fredric" To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] automated extended information gathering In-Reply-To: <200707072356.33088.vapier@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200707071743.44605.vapier@gentoo.org> <200707072319.40004.vapier@gentoo.org> <8cd1ed20707072031n6d4e47c7l4ea616660c6dcefb@mail.gmail.com> <200707072356.33088.vapier@gentoo.org> X-Archives-Salt: 313d9331-123b-4904-91d2-a6f990d474fe X-Archives-Hash: aeaa2e56db8cc01725e4c924df4cf2ce On 7/8/07, Mike Frysinger wrote: > On Saturday 07 July 2007, Kent Fredric wrote: > > On 7/8/07, Mike Frysinger 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 ` to walk the dependency tree and > include --info for all things that 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