Home_greyopenFATE - openSUSE feature tracking > #305715
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

Package event framework

Feature state

openSUSE-11.2
Rejected Information

Description

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

Relations

  • Duplicate of feature #313506:

Discussion


icons/user_comment.png F. L. wrote: (9 years ago)

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

Stano, Needinfo me back when you guys have a settled position or decide to postpone this one given the other priorities.

icons/user_comment.png K. K. wrote: (9 years ago)

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.

icons/user_comment.png M. S. wrote: (9 years ago)

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.

icons/user_comment.png K. K. wrote: (9 years ago)

Now thats good to know.

But this probably still needs a significant investment (and a fair bit of persuasion) into rpm4, I guess.

icons/user_comment.png C. C. wrote: (9 years ago)

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.

icons/user_comment.png K. K. wrote: (8 years ago)

The "rpm summit" which was held during the 2009 openSUSE conference brought us a big step forward here.

We've now established a healthy relationship with 'rpm4 upstream' and thus will _not_ move to rpm5 anytime soon.

Rpm4 will add 'file triggers' in a future version, makeing it possible to e.g. run 'ldconfig' if a library file was installed, updated or removed. A couple of other use cases come into mind for this.

---

I'd recommend to close this feature request for now and wait for rpm4 upstream to come up with a solution.

icons/user_comment.png J. W. wrote: (4 years ago)

This is actually covered in #313506.

icons/user_comment.png M. A. wrote: (4 years ago)

Yes, if libzypp is able to disable rpm executing posttrans scripts (AFAIK this option was recently added to rpm) and instead of this collects, unifies and executes them, we're almost done.

We need to define how posttrans scripts are unified to prevent multiple execution of the same script. E.g. by scriptfiles checksum (though this is fragile; slightly changing a script will cause double execution; but package maintainers can work around this by installing the script on disk and just calling it in the posttrans; SUSEconfig reloaded).

We need to define the execution order.

Last change: 4 years ago
Voting
Score: -1
  • Negative: 2
  • Neutral: 1
  • Positive: 1
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint