[packagekit] [GSOC] Recommender Systems
matthias at tenstral.net
Thu Apr 28 21:57:58 UTC 2016
2016-04-28 21:17 GMT+02:00 Lucas Moura <lucas.moura128 at gmail.com>:
> I have spoken with my mentor about the AppStream integration. The idea that
> he had was to create an AppStream library that would only manage recommended
> packages and why they were recommended, for example, displaying which
> installed user packages generated the recommendations. Therefore, the
> library would be generic enough to allow any package recommender system to
> populate it with recommendations. In that context, AppRecommender would only
> be used to generate the recommendation and pass them to the library. Does
> that make sense for an AppStream lib ?
With "does it make sense" do you mean "does it make sense to integrate
it into an AppStream lib"? For that, the answer would be: Depends on
different factors, e.g. the amount of added dependencies (because not
everyone needs that feature, and I don't want to have the lib pull in
too many dependencies (with Xapian and Protobuf, it already has a
In case it was meant "does it make sense as an own, separate library":
Yes, absolutely, I would say! GNOME Software at least also has an
awesome plugin architecture, which will make implementing this feature
there quite easy.
> I could not completely understand
> from Mr. Matthias email if the library should generate the recommendation or
> a approach similar to the one I am proposing here is also valid.
You mean the library just being an interface to some Python stuff
except for implementing the actual logic?
Well, theoretically just having any kind of C/C++ interface would be
enough to add a feature like this to KDE Discover and GNOME Software.
But my past experience with calling Python code from C has been that
it is so incredibly slow that most of the time rewriting the logic in
C is justfied.
We had this in PackageKit once, with the original "apt" backend, which
was spawning Python worker processes - any C/C++ backend outperformed
it, and for the "many small queries" case, it wasn't really up to the
task. Sure, you can optimize the Python<->C interface, but only to
> Also, since this discussion is now mainly focused on AppStream, I will move
> any other doubt about it to the appropriate email list. I am just sending
> this email in this list so that the whole context of the conversation do not
> get lost.
When writing to the AppStream list, you could just include a link to
the PK list thread as a reference, to anyone who's interested.
> On Tue, Apr 26, 2016 at 5:32 PM, Lucas Moura <lucas.moura128 at gmail.com>
>> Could the library plugin be an C/C++ API to AppRecommender ? Sorry if that
>> is a silly question, but I did not understand if the library should be a
>> re-implementation of AppRecommender using C/C++ or just a C/C++ API would
>> solve this problem.
>> Best regards,
>> Lucas Moura
>> On Tue, Apr 26, 2016 at 5:14 PM, Richard Hughes <hughsient at gmail.com>
>>> On 26 April 2016 at 21:10, Lucas Moura <lucas.moura128 at gmail.com> wrote:
>>> > On my bachelor thesis, a friend and I are trying to add context
>>> > information
>>> > to the selected packages, by looking at the most recent used packages
>>> > and
>>> > using a machine learning approach to better filter the recommended
>>> > packages
>>> > based on this contextual information.
>>> Yes, this makes sense. One thing I want to try when I've got more data
>>> is to use the stats from the ODRS review system and try to extract
>>> some patterns, e.g. users that install gimp.desktop also tend to
>>> install inkscape.desktop. At the moment there's about two orders of
>>> magnitude more data required.
>>> PackageKit mailing list
>>> PackageKit at lists.freedesktop.org
> PackageKit mailing list
> PackageKit at lists.freedesktop.org
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/
More information about the PackageKit