- openSUSE Software Management

[softwaremgmt] Locked packages in SLES10 break update
by Lars Volker 27 Jan '11

27 Jan '11

Hi everyone, we operate an own installation of the opensuse buildservice 2.0.4 and use it to build several php-related packages for various platforms including SLES 10 + 11. It happens only for SLES10, that automatic updates of our packages will fail. All packages coming from our repository are flagged as "locked" and zypper will not upgrade them. I also cannot find the lockfile in /etc/zypp/locks as suggested by http://en.opensuse.org/openSUSE:Libzypp_locksfile. When running "zypper install locked-package-name" it will complain about the locks. If one proceeds and selects "unlock" from the list of choices, then all packages will be installed, but each one will throw a dependency error during installation. I've read (German: http://www.linux-club.de/viewtopic.php?f=3&t=81259&sid=d48a82d276afac5e2c0e…), that any external package will be locked automatically in SLES10. Does this include external repositories (like ours) as well? The zypper version is very old on SLES10 and does not seem to support the lock-managing commands. sles10:~ # rpm -qa | grep zypp zypper-0.6.200-0.4.49 libzypp-2.100.3-0.4.23 libzypp-zmd-backend-7.1.1.0_2.16-0.4.46 I asked this on the opensuse-buildservice list, from where I was sent here. We already verified, that the packages are signed OK and that the GPG key is properly imported as well (rpm -qi). Now the question is: Is there a way our repository needs to be flagged, so that the packages will not get locked by SLES10? We rely on automatic upgrades of packages distributed from those repositories, so manual install is not a feasible solution. Is there a command in this old version of zypper to unlock the packages? With kind regards, Lars Volker -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

2 1

[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

[softwaremgmt] Autoenable-feature for services
by J. Daniel Schmidt 18 Oct '10

18 Oct '10

Hi, I'd like to discuss a new feature for (NU) Services. A service can contain multiple repos and they may change over time. All these changes are automatically apllied to the system during a refresh of the service. But one thing is missing IMHO. All new repos always remain disabled and have to be enabled manually. In the registration process we therefore enable each repo one by one. The server has no way to tell the client what repos should be enabled in his opinion. And the client has no possibility to change the policy to always enable repos in services. I'd recommend to add a new property to the repo definition in the repoindex.xml: enable="1". Repos tagged like this should be enabled (of course only in the opinion of the server). When a service gets added on a client the service should get a new parameter: autoenable=<value> in its service file (zypper needs to support it). The value might be one of: all = automatically enable all repos that the server has remote = automatically enable all repos that are tagged with enable="1" none = no automatic enabling - default (if missing), to be backward compatible By this, the authority still remains on the client. The client can decide what policy he wants to use. And the change of the policy is per service, so changing the policy for one service does not change for all services. This would be a nice feature for services as you could add one service that you trust (maybe you administer it yourself) and then forget about it, as the repos will always adapt automatically. I had short conversations with Duncan MacVicar and Marcus Meissner about this topic today but now want to open it for a discussion. What do you think? Are there better ways to do this? Are there side-effects or security issues? Ciao, Daniel -- J. Daniel Schmidt <jdsn(a)suse.de> SUSE Linux Products GmbH Research & Development Maxfeldstr. 5 GF: Markus Rex, HRB 16746 (AG Nürnberg) D-90409 Nürnberg -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

2 2

[softwaremgmt] Grouping OBS repos into services
by J. Daniel Schmidt 08 Sep '10

08 Sep '10

What do you think about the following idea? The openSUSE software management zypp knows about a service type called RIS [1] (sometimes referred to as NU type [2]). It allows to group repos together to a service that can then easily be added to the system. This would ease administration of many openSUSE installations. A user would just need to add his own or preferred service to his systems to get all needed repos assigned. It is even possible to later change the service as the software management will update the repo settings on a service refresh. The openSUSE project could offer a new webservice that allows any registered user to create such a service. Users could group any OBS project repos into a service, give it a name and a description. The webservice could look like this (see "services" as a placeholder): services.opensuse.org -> HTML: login and manage your services (group any OBS repos into services) services.opensuse.org/<user_name> -> HTML: list all repos of a user services.opensuse.org/<user_name>/<service_name> -> HTML: show the service with a short description and all containing repos services.opensuse.org/<user_name>/<service_name>/repo/repoindex.xml -> XML: deliver a service this is the place where the software managemanet looks for the service By default all home-projects of a user that are in the same hierarchy level could be available grouped as a service as well: services.opensuse.org/<user_name>/home:abc:KDE-5.5 or services.opensuse.org/<user_name>/home:abc:server:mailserver ... such services dynamically change when a new project is created. The openSUSE project could also offer some generic services like services.opensuse.org/opensuse/KDE-latest services.opensuse.org/opensuse/Gnome-latest services.opensuse.org/opensuse/Ruby-on-rails ... a.s.o. Easily possible as well: services.opensuse.org/pacman/Mediaplayer [1] http://old-en.opensuse.org/Standards/Repository_Index_Service [2] http://old-en.opensuse.org/Standards/NU_Service Ciao, Daniel -- J. Daniel Schmidt <jdsn(a)suse.de> SUSE Linux Products GmbH Research & Development Maxfeldstr. 5 GF: Markus Rex, HRB 16746 (AG Nürnberg) D-90409 Nürnberg -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

3 2

[softwaremgmt] dist-upgrade: another way of doing rollback?
by Jano Kupec 24 Aug '10

24 Aug '10

Just a brief brainlightning... 1) enable keeppackges for all repos (needs a lot of space) 2) create a snapshot (hardlink/copy) of /var/cache/zypp/packages at any point of time 3) use 'zypper dup --repo anysnapshot' with solver.upgradeRemoveDroppedPackages = true to install (downgrade/upgrade) from that snapshot and remove any others Could this be an acceptable solution? It does not roll back configuration and other stuff, but such type of rollback is also desired. https://bugzilla.novell.com/show_bug.cgi?id=506701 -- cheers, jano Ján Kupec YaST team ---------------------------------------------------------(PGP)--- Key ID: 637EE901 Fingerprint: 93B9 C79B 2D20 51C3 800B E09B 8048 46A6 637E E901 ---------------------------------------------------------(IRC)--- Server: irc.freenode.net Nick: jniq Channels: #zypp #yast #suse #susecz ---------------------------------------------------------(EOF)---

1 0

[softwaremgmt] [dwashington@gmx.net: [Rpm-maint] Announcment: The Psys Library]
by Klaus Kaempf 18 Jun '10

18 Jun '10

JFYI ----- Forwarded message from Denis Washington <dwashington(a)gmx.net> ----- Date: Fri, 18 Jun 2010 10:29:15 +0200 From: Denis Washington <dwashington(a)gmx.net> To: rpm-maint(a)lists.rpm.org Subject: [Rpm-maint] Announcment: The Psys Library Hello, I would like to announce a project to you which aims to attack the problem of cross-distribution, but distribution-integrated, Linux software deployment, and might interest you. It is a simple library written in C, called the "psys library" ("psys" standing for "package management system"). From the README: "The psys library provides a simple interface to the system package manager of a Linux system. It allows installation programs to notify the package manager of the installation, uninstallation and update of third-party software packages, and to request these packages to be added to or removed from the system package database. The psys library interface is generic and not tied to a specific package management system or Linux distribution. Note that the psys library is only useful for adding and removing software which complies to the Linux Standard Base (LSB) specifications [1]. Most notably, it is assumed that the data files of a software package are installed into /opt as demanded by the Filesystem Hierarchy Standard (FHS) [2], and that a package only depends on the interfaces and behavior specified by the LSB; any additional dependencies must be contained within the package itself. The psys library interface is meant to be a proposal for a future version of the LSB standard." Those who remember will notice that this is the same idea as the "Berlin Packaging API" proposal discussed on an LSB Packaging Summit as part of the LSB face-to-face meeting 2006 in Berlin. The aim was to bridge the gap between ISVs on the one hand, many of which have invested in cross-platform installers and would like to use those on Linux too (instead of having to make not only one, but mulitple additional packages in various formats for Linux deployment), and distributors, which would like all software to be centrally managed by their package manager of choice. By giving installers a way to communicate with the package manager through a simple, LSB-standardized library interface, both sides would benefit: ISVs could use their installer frameworks with only few changes, and distributors would gain control over software installed by such installers, integrating it into their package database. There seemed to be a general agreement at that time that this would be the right approach to go forward. For more details about what was discussed and why, see the two-part blog post on this matter by Ian Murdock (who attended the summit) [1]. Unfortunately, nothing really came out of that. No proof-of-concept sample implementation was created, leaving the whole concept kind of in a vaporware state. In 2008, I attempted to change that with a concrete design and implementation which I named the "Burgdorf Packaging API" [2]. Unfortunately, it was somewhat over-engineered (using technologies such as D-BUS, PolicyKit and XML) and would probably have required a too big amount of code changes to installers; and while it spawned some discussion (including the thread following my initial announcement on the LSB packaging mailing list [3], a blog post by PackageKit creator Richard Hughes [4] and a short OSNews article [5]), the outcome was, again, nothing. So now, two years later, I am trying again with the psys library. The concept stays the same, but the library is much simpler in design and implementation than Burgdorf. It is now just a simple C function interface; the complex XML-based metadata format has been replaced by programmatic definition of the metadata; and adopting installers to use the API should generally be much less work. The psys library is not just an idea or general design. There is a complete implementation, and I have tried my best to document the library interface as throroughly as possible. The source code and documentation can be found at the project's page on Gitorious [6]. The library implementation is split into a frontend and a backend part. The frontend is distribution-independent; it is implemented in the psys library source code itself. The backend, on the other hand, is thought to be provided by the distribution (or package manager); it does the hard work of ensuring that an installation attempted by an installer is sane (overwrites no files, does not conflict with installed packages etc) and of adding packages "registered" by an installer to the system's package database. The core psys library also supports the concept of "fallback backends", which can be used if the distribution does not support psys. These fallbacks allow the psys library to be used *now*, with no distribution-side changes, by linking it into the installer - this would allow a smooth transition period until the interface is supported by distributions directly. Currently, the psys library comes with a fallback backend for RPM-based distributions (tested successfully on Fedora 13 and openSUSE 11.2). I am naturally not writing all this to you without reason. I would like to ask you for help. * While an RPM fallback backend is already written and seems to work, I am not particularly fluent with rpmlib, so I might have made some mistakes. Would somebody like to have a look at the code in order to make sure it is reasonably correct? I do not want the backend to screw up any RPM database, so I would be thankful about some additional eyeballs. * I would like to know what you think about the psys library and the concept behind it in general. Could you imagine supporting such an interface in RPM? Or do you think the idea is fundamentally flawed, and that RPM should not support cross-distro installers in this way? I am very interested in your feedback and hope you can help me to make the vision of easy cross-distribution software deployment on Linux a reality. Best regards, Denis Washington P.S.: I sent a very similar message to the Debian's dpkg mailing list, too. History: [1] http://ianmurdock.com/linux/software-installation-on-linux-today-it-sucks-p… [2] http://www.linuxfoundation.org/en/Burgdorf_Packaging_API [3] https://lists.linux-foundation.org/pipermail/packaging/2008-June/000732.html [4] http://blogs.gnome.org/hughsie/2008/06/24/lsb-package-api/ [5] http://www.osnews.com/story/19901 Psys Library: [6] http://gitorious.org/libpsys -- To UNSUBSCRIBE, email to debian-dpkg-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4C1B2C1C.9010602@gmx.net _______________________________________________ Rpm-maint mailing list Rpm-maint(a)lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint ----- End forwarded message ----- --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

1 0

[softwaremgmt] Run download and install in parallel feature status
by Rastislav Krupanský 28 May '10

28 May '10

Hi all. I want to ask what´s the status of the most wanted feature #120340: Run download and install in parallel? Afaik, Milestone7 should be features freeze(sorry, if i´m wrong and correct me), but software management still uses traditional behaviour. Can we expect this feature will be added, or won´t? Or parallel download at least? If there is no plan to use it, could you change default behaviour to "DownloadInAdvance" in /etc/zypp/zypp.conf? Thanks a lot. -- S pozdravom / Best regards, Rasto -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help(a)opensuse.org

1 0