App Installer Miniconf

Thu Jan 27 17:00:42 UTC 2011

On Thu, Jan 27, 2011 at 09:53:08AM +0100, FlorianFesti wrote:
> 
> So the overall plan has 4 parts:
> 
> Static meta data that can be shiped within the repository and also works offline from a CD/DVD. This is not completely unlike the optional packages in comps but with a bit more data about the applications. The idea is to autocreate this data from desktop files - which may be enhanced a bit. We'll see how far this really works and if we need to add manually created data or not. So there is a mid term perspective to also add non GUI stuff to this but we'll go for desktop apps only in the first step.
>
We have this information in the Package Database currently.  You could
either look into what information you want in what format and we could
export it or look at taking the code and pulling it into a separate python
module where multiple sources can use the data extraction features.  I think
that I gave you links to the relevant code before so you probably have an
idea of which of those options is better.

> 
> For fancy new things like comments and ratings there will be servers where this data is stored and can be maintained by a user community online. There already is an API that covers this. The Social Desktop API "Open Collaboration Server" (OCS) has a module for "content" - applications in our case. How exactly the OCS will be used is still to be determined. This is really not my area of expertise. As far as I understood you can have per user account and friends and suggestions and what ever or just comments and ratings. This is probably up to whoever is going to actually run the service.
> 
<nod>  The packagedb has this functionality for Fedora but not the APIs.
Talk to mbacovsk about adding it.

> Screen shots will be stored on a different (http) server but linked from the OCS. As there already is screenshots.debian.net we might use that (via proxy) for the start before we setup something like that on our own. (Elite diplomats looking for a challenge can also go for an agreement for a shared server.)
> 
This would be good to add.  mbacovsk was talking about his plans in this
area with me a few months ago but using resources that are already available
might be good -- at least in the short term.  Differences between distro
theming of GUI apps and such might prove problematic in the longer term but
that's a decision that could probably be deferred.

> These three data sources are then brought together within the client. The idea is that as there are different repositories there also are different OCS servers - either providing information for different applications or different information on the same applications. This way comments or ratings could be shared between distributions without any of them loosing control over their own data. Details being determined by the per distro or even per user configuration.
> The client can be an GUI application or a server offering a web interface (IIRC one of the Mageia guys said he's going to write one). To get a GUI client there will be some steroids added to the Ubuntu Software Center which already has a similar functionality using it's own data formats and protocols.
> 
The PackageDB has a webui for this -- with several noticable bugs.  If
someone wants to help, I think mbacovsk would appreciate the help.
> 
> Ok, this is the overall plan. There already is an announcement containing more technical details and further pointers:
> 
> http://lists.freedesktop.org/archives/distributions/2011-January/000411.html
> 
> Be aware that there are still a lot of people to convince (including you) and technical issues to solve to really make that happen. Take the technical details with a grain of salt. Also there will need to get more people involved. I'll give a talk on the upcoming FudCon to help with that.
> 
> 
> Florian
> 
> 
> PS: There are two side project that I personally consider as interesting: The first is a way to match packages between different distros. I could imagine that the package db offers links to the specs and patches of the other distributions. May be someone in this area wants to pick that up.
> 
<nod>  This would be very interesting -- many of the times when talking
about packaging and cross-distro stuff we run into the fact that naming of
packages and dependency information is not portable between distros.  If
someone wanted to solve that it would be great (note that it's not something
that has blocked anything critical that we wanted to do so it's not
something we've spent time working on -- it's more something that has
blocked several optional features in various projects I work on.

> Second thing may be adapting the Debian tagging system (Debtags) for Fedora. With the package matching in place we could start with a quite big data set instead of zero. But there probably also is quite some work to do - and be it just porting their tools from dpkg to rpm...
> 
When implementing tagging in the PackageDB, Debtags was something that we
looked into.  IIRC, we decided they were overengineered for what tagging is.
(Perhaps better for a Category model than a tag model).  I don't recall
offhand what specific features of debtags we decided were either unnecessary
or going to cause problems but if someone does want to work on debtag
integration, be sure to think about the complexity costs and who is going to
enter the debtag information when you do so.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110127/e268ac19/attachment.bin