Feature changed by: Stanislav Visnovsky (visnov) Feature #305715, revision 17 Title: Package event framework openSUSE-11.2: Rejected by Andreas Jaeger (a_jaeger) reject date: 2009-06-09 14:44:19 reject reason: We're not going to manage to do this for 11.2. If rpm gets all the changes, we can incorporate this later. Priority Requester: Desirable - Info Provider: (Novell) Requested by: Andreas Gruenbacher (agruen) Product Manager: (Novell) Product Manager: (Novell) Project Manager: (Novell) Technical Contact: (Novell) Technical Contact: (Novell) Partner organization: openSUSE.org 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.) Discussion: #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 involved. 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. #6: Klaus Kämpf (kwk) (2009-09-22 12:35:25) 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. -- openSUSE Feature: https://features.opensuse.org/305715