openSUSE Software Management November 2010

softwaremgmt@lists.opensuse.org

13 participants
4 discussions

[softwaremgmt] Software Portal
by Pascal Bleser 15 Nov '10

15 Nov '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just to give some more meat/background to the discussion, here are the ideas that lead us (Benjamin Weber and I) to implement the Software Portal (http://software.opensuse-community.org): 1) Applications - --------------- Newbies shouldn't be exposed to "packages" and only to a very limited extent to repositories, but, rather, to "applications". That means that they should be able to search for "firefox" or "amarok" in a central place and be able to install it easily from there. No libraries, no development packages, and applications being bundles of 1-n packages. Tagging is obviously a very useful tool for navigation as well, as people might just want to look for "games" or "email" instead of having to know the name of the packages/applications. 2) Web-based - ------------ The idea was also to have them use their web-browser to search and install stuff, as that is what most people just do. OneClickInstall (which was originally written by Benjamin Weber too) is used to trigger the package installation when they click on an "install" button. For those who don't know, it's implemented through the MIME type and handlers in the openSUSE packages of Firefox and Konqueror (as opposed to what Debian is doing through the "apt://" URIs which, we believe, is just plain wrong as to the RFC standards). There are some problems with OneClickInstall, such as still being too complex for newbies, and Garrett made some interesting mockups (*) for a nicer UI as well as a somewhat easier workflow. But one way or another, you _cannot_ relieve end-users from having to care about digital signatures. And that's really the key problem regarding usability (or rather easy of use) here. (*) http://linuxart.com/log/archives/2010/06/21/one-click-part-2/ 3) Use repository metadata - -------------------------- As we didn't think that there would be enough people to maintain/define applications manually, we took the route of having a software based solution that automatically defines/detects applications from package repository metadata using some heuristics. As already mentioned in my previous posts, a few of those heuristics are: * look for a .desktop file in the files list of a package (which identifies a package as being an application, because it'll show up in the menu) * merge packages based on their %{SOURCERPM} RPM metadata tag to assemble them as applications (which catches subpackages) * the ability to define regular expressions to match additional packages with an application * use categories from the .desktop file to define tags on the application One problem became clear once it was implemented and up&running: we have way too many repositories to be able to process all that metadata properly, at least without having to scale out to several servers. The RPM-MD metadata is fetched every hour, and it regularly clogs down the server when it has to process all that data. We did optimize the SQL to the MySQL instance quite a lot, so that's not the problem. The issue might be that we also do compute a lot in the database to detect - - new applications (that have been added) - - updates to existing applications - - applications that have been removed and all that requires quite some juggling in the database. Having OBS (or rather the OBS publisher) ping the system would be a great plus, simply for the sake of a simpler implementation, live content, and scalability. 4) User feedback - ---------------- Screenshots, ratings, comments, all of that was obviously implemented as well. We also wanted (but didn't implement) to be able to link to blog posts, openSUSE forum threads, etc... The idea with rating was to give users a quick look at whether the application packages can be trusted. In our implementation, only blessed users were allowed to give ratings. And no, we obviously didn't use iChain as an authentication and/or authorization backend, we have our own user+role database ;) 5) Desktop client - ----------------- Once the Software Portal had been finalized (**), we would also have expanded the REST API in order to make it possible to implement a desktop client. The desktop client wouldn't need OneClickInstall and would also know about which packages are installed on your system, hence offering an even better user experience. But it never got that far. (**) which never happened due to lack of interest from others (we made a presentation about it at the openSUSE conference in 2009 (***), as well as blogged about it quite extensively back then, which is why I'm surprised so many people never heard of it -- yes, I do hate you people for that), and because Benjamin and I simply didn't have enough time on our hands to continue implementing it on our own (***) the PDF of the presentation is here: http://linux01.gwdg.de/~pbleser/swp.pdf More details on the wiki page we wrote back then: http://old-en.opensuse.org/Software_Portal Some screenshots: http://bw.uwcs.co.uk/swp/ cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser(a)skynet.be> <guru(a)unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iD8DBQFM1Urtr3NMWliFcXcRAhFFAKCE4RTwzNXBKbfcI4zuXvUlm1BPeACeKb0O x/byDkvQnZehEbfhNcdfiAQ= =0ZCE -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

5 7

Re: [softwaremgmt] Our software store
by Thomas Goettlicher 13 Nov '10

13 Nov '10

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(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

2 1

Re: [softwaremgmt] Our software store
by Thomas Goettlicher 08 Nov '10

08 Nov '10

On Tuesday, November 02, 2010 02:47:16 pm Jiri Srain wrote: > There was a keynote at the openSUSE conference on Saturday which was held > by Frank Karlitschek. He talked about the Praetzel project, which > includes, among other parts, an app-store and has currently ready three > clients. > > I tried to find the project and fialed - perhaps because I did not get the > name correctly, as it is a word in the Bavarian dialect. As it is supported > for MeeGo, which uses in genral the same update stack as openSUSE, it could > be on option to use it at openSUSE. > > Jiri > See: http://news.kde.org/2010/11/02/frank-karlitschek-introduces-bretzn Cheers Thomas -- Thomas Goettlicher SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

5 5

[softwaremgmt] Our software store
by Duncan Mac-Vicar P. 06 Nov '10

06 Nov '10

Following up with the discussions that took place in the openSUSE conference, I would like to kick off a discussion that has as an objective to come up with a step-by-step plan on how to - Make it ridiculously easy for the users to find & install the ridiculously good software This has various possible technical solutions. But the output has to be: - a "place" where the user can click and see the available cool software (ie: Chromium" not ie: libhenne-devel) with screenshots, ratings, comments - The user should not care about repositories and their combination requisites, or strange signature dialogs - Other pieces in the distro need to be integrated, or at least it would be nice to, for example we ship KPackageKit which is a lovely app if you show a bunch of apps separated by groups, but gets completely unusable if you show 2135 packages with strange names in one category in a simple list-view. Other pieces don't, like zypper, YaST2 which are mean to be used as package managers. - Whatever new opportunities we are able to get done in the process. For example, Frank's project bretzel has components that fit int he backoffice, aiming for a one click publishing of software from the developer's side (using adrian's _service's) which fits ridiculously great in our build service story. Cheers -- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

8 16

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openSUSE Software Management November 2010