Mailinglist Archive: opensuse-features (499 mails)

< Previous Next >
[openFATE 305715] Package event framework
  • From: fate_noreply@xxxxxxx
  • Date: Thu, 29 Jan 2009 13:15:13 +0100 (CET)
  • Message-id: <feature-305715-10@xxxxxxxxxxxxxx>
Feature changed by: Andreas Gruenbacher (agruen)
Feature #305715, revision 10
Title: Package event framework

openSUSE-11.2: New
Requester: Desirable

Requested by: Andreas Gruenbacher (agruen)
Partner organization:

The installation, upgrade, or removal of several packages triggers
actions such as running ldconfig, rebuilding the initrd, or similar.
Those actions are not specific to the package at hand, but either
global with a system-wide effect (such as running ldconfig), or they
affect a group of packages (such as all kernel (sub-)packages of a
specific version, including all KMPs affecting it). Those actions need
to be run eventually (with order restrictions relative to other package
installs, upgrades, or removals), but running them again and again for
each package is wasteful.
(Example: with the kernel packages split into kernel-$flavor-base,
kernel-$flavor, and kernel-$flavor-extra in CODE11, we currently run
- mkinitrd in the %post script of each package. We don't know which of
- those packages will be installed, and when generating the initrd is
+ mkinitrd out of the %post script of each package. We don't know which
+ of those packages will be installed, and when generating the initrd is
supposed to succeed. This both wastes time, and we also cannot tell
transient from permanent failures.)
In former days, SuSEconfig was used for some of those tasks, but it
turned into a major nightmare (perhaps due to its design).
It would be nice if we could come up with a framework in which packages
can trigger events and define which actions they need to be run, and
rpm will then perform those actions in an appropriate order, avoiding
repeating the same action unnecessarily. (The dependencies between
actions and package installs/upgrades/removals are somewhat complex,
but I think they are manageable.)

#1: Federico Lucifredi (flucifredi) (2009-01-23 18:09:34)
This is desirable only as it happens within RPM's framework (or if the
additions are "candy" that does not affect the actual result). This
includes upstreaming.
I do not want to comment besides the RPM requirement until Engineering
determines how (and if) to proceed. There are too many factors
Stano, Needinfo me back when you guys have a settled position or decide
to postpone this one given the other priorities.

#2: Klaus Kämpf (kwk) (2009-01-29 12:45:22)
Actually, there is probably litte engineering can do or decide here
imho. It very much depends on PMs long-term strategy for RPM.
There are currently two options
* One is to stay with rpm 4.x and keep the status quo.
* The other is to move up to rpm5 and try to influence its development.
Upstream implementation of the feature request can only happen within
rpm5. Adopting rpm5 for the distribution has several prerequisites:
* Investment into rpm5 development.
* Getting more distributions to adopt rpm5.
* Influencing Linux Standards Base to accept rpm5.
Given recent comments from RedHat/Fedora, widespread rpm5 adoption
looks rather unlikely.

#3: Michael Schröder (mlschroe) (2009-01-29 12:50:19) (reply to #2)
That sounds like rpm-4 doesn't get new features at all, which is simply
not true. Actually I think it's probably easier to get new features
into rpm-4, because it's very hard to convince Jeff of something he
doesn't like, whereas Panu is more open.

openSUSE Feature:

< Previous Next >
This Thread