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
pgpSzN9iylbq2.pgp
Description: PGP signature
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
