Re: The Future of Bug Buddy

[Colm Smyth <Colm Smyth ireland sun com>]

Hi Jacob,

Bug Buddy is a very valuable GNOME tool, it's great that someone
has taken on the task of enhancing it!

I do most of my work on Solaris (that may come as no
great surprise!) where there is a tool pldd to
list the shared objects loaded by a process.
There is at least one effort to create a similar
tool for Linux (see 
http://csociety.ecn.purdue.edu/pipermail/plug/2000-May/002417.html)

If Bug Buddy ran pldd (or similar) on a process before it
terminates, it then knows at least the runtime code dependencies
of the application and could find the version number of each
shared object accordingly. This can be done without the need
for a package description or a specialised file for Bug Buddy's
use.

This leaves out things like versions of configuration files,
data files, etc. that may cause an application to crash,
but it's difficult in any case to get version numbers for
the various files an app may use so this may not be
such a great loss.

Would this meet the information requirements of Bug Buddy
without the need for additional meta-data files?

Colm.

>Delivered-To: gnome-hackers gnome org
>To: Maciej Stachowiak <mjs eazel com>
>Cc: gnome-hackers gnome org
>Subject: Re: The Future of Bug Buddy
>From: jacob helixcode com (Jacob "Ulysses" Berkman)
>User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (GTK)
>MIME-Version: 1.0
>X-BeenThere: gnome-hackers gnome org
>X-Loop: gnome-hackers gnome org
>X-Mailman-Version: 2.0beta5
>List-Id: <gnome-hackers.gnome.org>
>
>Maciej Stachowiak <mjs eazel com> writes:
>
>> > Since some people are still using GNOME from sources rather than
>> > packages, bug buddy should work around this nicely.  What I am
>> > thinking of doing is having every module supply a bug buddy file which
>> > includes things like the list of binaries it provides, a list of
>> > things to check for, and where the email should be sent.  Also, a
>> > mapping of which packages come from the module would be provided,
>> > since bug buddy needs to know that and I haven't thought of anywhere
>> > else it could get this.
>> 
>> If building from source still provides all the needed dependency and
>> version info, why involve the packaging system at all? Why not just
>> install these bug-buddy files with the packages?
>
>Because the source stuff doesn't actually provide everything, just the
>gnome-level stuff.
>
>For example, it probably won't be able to say which libpng or other
>non-gnome libs you have.
>
>The thing is that it is much easier, and actually more informative to
>query the rpm / dpkg databases if you are using package based gnome
>than to just check the version of the module (ie, libgnome32 1.2.8-5
>is more informative than just gnome-libs 1.2.8, as the package may
>have changed).
>
>So yeah, the duplication here sucks, but is really not all that big
>and I think makes sense.
>
>> Also, I assume libredcarpet will be available in source form by the
>> time this version of bug buddy is released. Will it also be available
>> on a publicly accessible cvs server (for instance cvs.gnome.org) by
>> then?
>
>Yeah, I won't be releasing or putting this version of bug buddy into
>the CVS until libredcarpet has been released in some form.  I don't
>know what this schedule is, but it probably won't delay the releasing
>of bug buddy as there is still quite a bit of stuff left to code.
>
>Jacob
>-- 
>"I've got nothing to say but that's ok." -- John Lennon
>