On Saturday, November 06, 2010 01:32:32 pm Pascal Bleser wrote:

On 11/04/2010 01:55 PM, Duncan Mac-Vicar P. wrote: [...]

...

So we could start with a helper to pull some app data from OCS into desktop.db while KPackageKit gets real OCS support. At least it would solve our problem of a friendly updater.

Sorry but I don't see the relationship between "applications" and "packages". The one big thing about an """AppStore""" is that we need to show "applications" to the end-user, and not packages, where applications are actually bundles of 1-n packages.

Let's just have the existing infrastructure handle package updates when it comes to patches, upgrades and fixes.

This is an entirely different beast altogether.

And we really have to make some decisions upfront because from a technical perspective, they do make a big difference. One key item is whether we want those "applications" to - be assembled/defined manually through user/admin input - be automatically assembled from package repositories, through heuristics (*) - something in-between, where package repository metadata is assembled through user/admin input

(*) That's the path we took for the Software Portal (**), some heuristics having been implemented there (such as looking for .desktop files in the package, match packages on their %{SOURCERPM} tag to assemble them as an application, etc...).

(**) http://software.opensuse-community.org

And another thing to keep in mind: we're getting into exactly the same problem as with the "community repositories" thingy: if it is hosted on opensuse.org, we won't be able to have applications that are in Packman. We could provide installation of applications hosted by packman too if the user wants to use community repos. Technically we just provide the infrastructure for package installation. It's up to the user to install applications from trusted vs. untrusted sources.

Furthermore, the whole thing will definitely need specific support in the OBS, in order to ping repository changes to the system, as pulling repository metadata on a regular basis does not work, the current Software Portal being a proof of that (way too many repositories, way too much metadata, completely hogs the server). But I already started discussing that with Adrian, as I'm working on a replacement for the "webpin" package search (both frontend and API), based on a real search engine (Apache Solr) rather than on a database, and I'll need the OBS' publisher to make calls to webpin whenever changes happen.

...

The need for a packagekit based updater is that we have features like notifications of patch messages, distribution upgrade notifications and start of the dist-upgrade workflow, etc.

I'm not sure. As said above, I'd rather let that be handled through repository metadata, as it is now, and instead focus on how packages can be presented as applications to end-users.

cheers

-- Thomas Goettlicher SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org