openSUSE Software Management

Download

softwaremgmt@lists.opensuse.org

June 2010

1 participants
2 discussions

[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] [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