[Bugsquad] Debug packages in Shaman

[Dario Freddi]

On Sunday 27 December 2009 21:53:52 Darío Andrés wrote:
> 2009/12/25 Dario Freddi <drf54321 at gmail.com>:
> > Hello people,
> 
> Hey! :) (and sorry about the delay)

Hey back :D

> 
[snip]
> 
> I will briefly explain how we get debug symbols packages installed:
> 
> - From the incomplete backtrace, we get the path of the .so libraries
> with missing debug information.
> (ex. "/usr/lib64/libQtCore.so.4")
> - Using that path we get which packaged installed it
> (ex. "libqt4")
> - Now we check which package contains the debug symbols of the
> previously fetched packagename
> (ex. "libqt4-debuginfo" contains the debuginformation for "libqt4")
> - Those packages get installed
> - The backtrace is regenerated. (and hopefully complete now :) )
> 
> So, from a "package management" PoV we need to:
> - Check which package ("A") contains a file
Ok
> - Check the debug info package ("B") for the package "A"
See next point
> - Install the package "B"
Ok
> 
> It is usually done this way. May be you can think of a better workflow
> to install the missing debug symbols package; may be using some other
> functions we can bypass the step 2. (so it will be: fetching the
> debuginfo packagename from the library file path)

The problem with checking which package has debug info for another is that is 
not easily abstractable and portable: on my platform (arch), for example, 
there's no way to determine which package carries debug information for the 
other because the backend simply does not support it, and guessing names is a 
bad game. I think a better workflow (that can be ported around backends 
without too much hassle) is the following (sorry for the pseudocode, but I 
need to think worst case here):

 - Check which package contains file A
   if backend does not support searching through package files or nothing is 
found:
    do a recursive search of the library name, if nothing was found, fail 
badly, otherwise, apply the next point to each package found

 - Search the package name in the backend. In the search result, consider only 
the packages marked as "debug packages" (obviously -.-). If none was found, 
try stripping the name (lib-qt-4 with debug symbols in qt-debug) or looking 
for metapackages names[1].

 - If more than one package is found and there's no way to refine the search, 
prompt the user the choice to install one, some or both

 - Install the packages (you can easily display the progress of the operation 
thanks to the handy http://api.kde.org/playground-api/sysadmin-
apidocs/shaman/html/classShaman_1_1TransactionInterface.html )

 - Profit!!

As you can see it's a bit more complex, but has a greater probability of 
success, especially when the backend has no knowledge of the relation between 
a package and the package containing its debug symbols.

Now, you could probably tell me that I could also add a way to retrieve 
packages based on properties, but I would like to avoid that. Let's have a 
quick glance at the libshaman api:

AbstractPackage (the base class of each and every package, and the one you'll 
have to deal with) has a flag Properties. So you simply

if (package->properties() & DebugInformationProperty) blablabla

However, you might say, I could add a method which returns a list of packages 
in relation with a property, like

AbstractPackage::List debugSymbols = package-
>relatedPackages(DebugInformationProperty | DevelopmentPackageProperty);

And get the job done earlier. However, I'd like not to do this: first of all 
because abstracting it would be a pain and we'd end up reinventing packagekit, 
which invented a new packagemanager which is supposed to be a wrapper, and 
secondly, (and as you can see this reason is connected to the first) because 
as I said I imagine very few backends would be able to provide such an 
information.

Remember that the very first target I want to achieve with libshaman is 
portability: no compromises when it's a matter of letting a backend expose the 
best information possible. That's where packagekit oddly failed and we 
definitely don't want to do the same mistake.

This is where everyone wins: having a slightly more complex procedure but 
reach all the possible available audience. For example, through providers[2], 
libshaman could be completely used, feature full, with systems like portage or 
ports (BSD). If you know what ABS and AUR in Archlinux are, know that there is 
a Provider for both of them which allows managing packages coming from there 
in the main Shaman view. This should give you a vague idea of the flexibility 
of the whole stack :)

Sorry, the mail grew a bit long ^^

[1]: MetaPackages are a mean libshaman uses to group packages that "provide" a 
package name. This means, for example, that a backend could expose the package 
libqt4 under the names qt, qt4, libqt. In this case, LibShaman will have a 
metapackage for qt, for qt4, and for libqt, and all three of them will hold a 
reference to the real package. Anyway, for an early preview of the API (which 
is in constant change anyway): http://api.kde.org/playground-api/sysadmin-
apidocs/shaman/html/classShaman_1_1AbstractPackage.html

[2]: Highly work in progress: http://api.kde.org/playground-api/sysadmin-
apidocs/shaman/html/classShaman_1_1Provider.html

> 
> > Have some nice holidays, /me gets back eating
> 
> Happy holidays for you too.
> Thanks for all your work, and have a nice and productive 2010 ;)

Thanks, you as well :)

> 
> Greetings
> 
> Darío A.
> 
> > --
> > -------------------
> >
> > Dario Freddi
> > KDE Developer
> > GPG Key Signature: 511A9A3B
> 

-- 
-------------------

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/bugsquad/attachments/20091227/a73c95a1/attachment.sig