Hi, Manfred Hollstein schrieb: > This would be a design error in the first place, I'd say, as rug knows > (should know, at least...) about the _whole_ set of transactions, so it > should run SuSEconfig just once, which is at the end of the whole set of > transactions.
That's just a misunderstanding, rug does the same thing as apt and YaST do (I define installing/updating/removing multiple packages at once a single transaction), but it's still too much and too slow. > No, you don't want to run e.g. "ldconfig" after _each_ RPM you're > installing... That's exactly what happens currently(!): Every package that contains a shared library runs ldconfig in %post and then, at the end of the transaction, the package manager runs it _again_ (ldconfig is not strictly speaking a SuSEconfig module, but run together with SuSEconfig). It's inefficient and it hides bugs (missing ldconfig calls) in the packages. The same for SuSEconfig.fonts: All font packages (should) run it in %post, but at the end of the transaction, the package manager runs it _again_. Maybe the SuSEconfig modules can be divided into different classes: A class of general-purpose modules where running them after every transaction is more efficient and another class of special-purpose modules where running them after installing the individual packages which need it is more efficient. This split could be based on the classes posted by AJ, but it's not exactly the same: I'm thinking of a split based on how often and when a SuSEconfig module is actually needed, not based on how it works internally. For example, nobody would ever make a SuSEconfig module around mkinitrd although rebuilding the initrd is a task which resembles that of certain SuSEconfig modules. At least some of the existing modules can surely be handled like mkinitrd, i.e., run as needed. Andreas Hanke --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
