[Bugsquad] Debug packages in Shaman

[Dario Freddi]

On Monday 28 December 2009 01:19:05 George Kiagiadakis wrote:
> Hi,

Hey :)

> First of all, sorry for not replying immediately, I was a bit busy
> with my family reunion for the Christmas :)

Np, my mail was written in a rush as well ;)

> Secondly, thanks for taking care about this feature :)

:)

> 
> Let's get to the subject now...
> 
>[snip]
> 
> When I designed this, the abstraction I chose to follow is this:
> Step 1) Get names (with paths) of the binaries that lack debug symbols
> using the backtrace as the source.
> Step 2) Pass them as arguments to the distro-specific backend which
> will hopefully install their debug symbols.
> The distro backend currently is a shell script that distributions
> should provide. DrKonqi doesn't do anything more than that. The distro
> backend can use any way that it likes to get those symbols.

Hmm, now that you put it to me this way, I have to retire what I said to Dario 
in the last mail, this approach probably makes some more sense. How about this 
possible scenario (not yet in LibShaman API, it's just a proof of concept so 
we can work on the idea and I'll implement it).

Shaman::CoreInterface would change its search method to something like that:

QUuid search(const QString &search, SearchTypes type, 
AbstractPackage::Properties matchingProperties = 0, MatchTypes matchType = 
MatchingPackages);

Now, how would you use this interface? Let's have a look at the enums. 
SearchTypes will contain:

BasicSearch = Very basic and fast search, look into package names
ExtendedSearch = Perform an extended search, which results will depend on what 
the backend will provide as the searching mean
FileSearch = Given a path, searches in the backend's files
MoreSearches = If you have other ideas :)

The other two are a filter. matchingProperties will be able, if different from 
0, to list back only packages which have the defined property/ies. 
AbstractPackage::Properties, at the moment has the following possibilities

DebugInformationProperty = What you're interested in :)            
UnstableProperty = An unstable package, e.g. coming from a testing repository
DevelopmentPackageProperty = Carries development files, e.g. -dev packages in 
Debian

MatchTypes will return packages corresponding to the MatchType you specified, 
which are:

MatchingPackages = The default, returns the matching packages
RelatedPackages = If properties were defined, returns a list of packages 
related to the found ones, based on the properties.

DrKonqui will have to do the following:

QString absoluteFilePath = blablabla;
m_searchId = Shaman::Base::instance()->core()->search(absoluteFilePath, 
FileSearch, DebugInformationProperty, RelatedPackages);

connect(Shaman::Base::instance()->core(), 
SIGNAL(searchCompleted(QUuid,Shaman::AbstractPackage::List), this, 
SLOT(slotSearchCompleted(QUuid,Shaman::AbstractPackage::List)));

In slotSearchCompleted see if the completed search is yours (with the uuid), 
and take the results. Internally, the backends will have to implement their 
own means of searching. The API is not the best possible, I might even go for 
a Search class, but that's the principle. Of course, once you get an 
AbstractPackage::List you can simply do:

foreach (AbstractPackage *package, list) {
	package->setAction(AbstractPackage::Install);
}

Shaman::Base::instance()->core()->processQueue();

And then you just have to monitor the progress and (hopefully not) errors.

What do you think about that?

> 
> I chose this abstraction because I found that it can work in the
> distributions that I had a look at. As a proof of concept, I
> implemented 3 distro backends (which can be found in
> kdebase/runtime/drkonqi/doc/examples), which I'll try to explain how
> they work:
> 
> 1) The debian backend
> Debian currently doesn't have any native package manager support for
> debug symbols packages, although it is planned to add support in the
> near future. The sure thing about debian (and at least debian kde
> packages) is that given a binary with its absolute path (ex.
> /usr/bin/kwrite), its debug symbols are in /usr/lib/debug/$BINARY (ex.
> /usr/lib/debug/usr/bin/kwrite). So, the backend just uses apt-file to
> look for the package that contains this file (the /usr/lib/debug/...
> one) and then it installs it. This is sub-optimal, since apt-file
> takes a lot of time to search and it also needs to update its database
> from the internet, but it will hopefully be improved when apt has
> native support for finding debug packages.
> 
> 2) The opensuse backend
> Opensuse's package manager (zypper) has native support for this
> feature, using build-ids. Each binary has a build-id embedded in its
> .note section (iirc) and there is a tool to tell you the build id of
> any given binary. Then zypper can automatically install the debug
> symbols given the build-id (using "zypper install -C
> debuginfo(build-id)=$buildid"). This is very fast and very reliable,
> since the build-ids are unique, given to the binary at build time
> using some hash function and they are stored in the packages database
> as if they were packages, so that the package manager can install them
> very easily. (Note: Debian is also going to use a similar system with
> build-ids in the near future.)
> 
> 3) The fedora backend
> Fedora supports the scenario that Dario Andres described. First you
> retrieve from the rpm database the package that provides the given
> binary, then you use their custom "debuginfo-install" program which
> takes a package name as an argument and it installs its debug symbols.
> 
> As you can see, in all 3 backends, the input is just the absolute
> paths of the binaries that are missing debug symbols, and this seems
> to work nicely for all 3 distributions. So, if you think shaman could
> provide the same interface, then I think it would be the best, to
> allow drkonqi to have a shaman backend using the same interface that
> it uses for the other backends and let distros choose whether they
> want to use the shaman backend or their own.
> 
> 
> Best regards,
> George
> 

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

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/20091228/19801b12/attachment.sig