Mailinglist Archive: opensuse-features (226 mails)

< Previous Next >
[openFATE 305715] Package event framework
  • From: fate_noreply@xxxxxxx
  • Date: Sat, 28 Feb 2009 15:06:07 +0100 (CET)
  • Message-id: <feature-305715-12@xxxxxxxxxxxxxx>
Feature changed by: Casper Clemence (maninalift)
Feature #305715, revision 12
Title: Package event framework

openSUSE-11.2: New
Requester: Desirable

Requested by: Andreas Gruenbacher (agruen)

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 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.

#4: Klaus Kämpf (kwk) (2009-01-29 13:22:30) (reply to #3)
Now thats good to know.
But this probably still needs a significant investment (and a fair bit
of persuasion) into rpm4, I guess.

+ #5: Casper Clemence (maninalift) (2009-02-28 15:05:35)
+ I don't know about the issue of how the installer works but from a user
+ perspective the handling of multiple kernel flavours could certainly be
+ better. At the moment a symbolic link is automatically created at
+ /boot/vmlinuz pointing, rather arbitrarily IMO, to the most recently
+ updated kernel. Also the grub menu is messed with in an inept sort of a
+ way.
+ If instead symbolic links were created for each kernel flavour there
+ would be no need to change the grub menu except when new flavours were
+ installed or others removed, thus preserving all of the users other
+ boot settings.

openSUSE Feature:

< Previous Next >
List Navigation
This Thread
  • No further messages