The store on openSUSE

[Frank Karlitschek]

On 30.01.2011, at 11:46, Duncan Mac-Vicar Prett wrote:

> On Sat, Jan 29, 2011 at 8:21 PM, Frank Karlitschek <karlitschek at kde.org> wrote:
>> we discussed two basic modes during the AppStream meeting. First the mode where a lot of the metadata comes from the appdata.xml and only the community data like ratings and comments from ocs. And the second more called "discuvery mode" where all the metadata comes from ocs and you search on ocs to find applications.
>> 
>> The first mode works well if you have basically only one central repository.
>> The second mode makes it possible to also find application from outside the central repository. I prefer the second mode because it makes it possible to find and install applications from sources like for example OBS.
>> 
>> So the architecture would be to have the appdata.xml on the server and make the data available via ocs.
>> I think it would be cool for opensuse to implement an OCS server for OBS so you can find and install applications from all different repositories. I think the current client already works like this. But I´m not sure if it handles ymp files correctly.
> 
> Ok, so you mean implementing the "content" part of the API directly in
> the build service?

Yes. This would be an option. Or an OCS independently from the build service that points to the right packages/repos


> What scares me about this is that either the user needs to know about
> repositories (which is the whole thing we want to avoid: repos and
> packages), or we try to handle them transparently (which is not easy
> if you assume the world is something so wild and chaotic as the build
> service).

Hmm. O.K.
I think it is a good idea to be able to install application from outside the main openSUSE repository.
Something like a buildservice community repo perhaps.
This would make it possible to make third party application available independently from the the openSUSE release cycle, 


> In any case I would like to avoid using ymp unless we teach PackageKit
> to handle them so that:
> 
> - it is silent and almost non interactive, or at least if anything is
> asked, it is a relevant and nontechnical question
> - it does not ask for the root password
> 
> Right now the ymp handler is still pretty technical for what we are
> trying to solve.


Hmm. O.K. I now what I mean.
I´m not an packagekit expert. Can´t we just trigger the same code that currently handles the yml link from the browser?



Cheers
Frank



--
Frank Karlitschek
karlitschek at kde.org