[Bugsquad] Debug packages in Shaman

[George Kiagiadakis]

On Mon, Dec 28, 2009 at 3:04 PM, Dario Freddi <drf54321 at gmail.com> wrote:
> 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 think it makes sense, at least from DrKonqi's POV. However, I am a
bit skeptical about the existence of so many flags, as I'm afraid that
the backends will have a hard time to implement support for all
various combinations of them. But on the other hand, I may be wrong. I
definitely need to have a closer look at the rest of the shaman api to
understand a bit more about its design and how that fits the various
existing package managers.

Keep up the good work!

Regards,
George