[Bugsquad] Debug packages in Shaman
Dario Freddi
drf54321 at gmail.com
Sun Dec 27 22:44:34 CET 2009
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
More information about the Bugsquad
mailing list