On Wed, 2014-12-03 at 07:57 +0000, Eran Ben Natan wrote: > Look at the following scenario: A requires B. B, in the %post, runs an activity that is essential for A. If you install A with YUM, and that activity of B fails, YUM will install A anyway, but A will not be functional because the %post of B failed. > Checking that the %post of B completed successfully in %pre of A will prevent that situation. Read what Panu said again: Panu Matilainen wrote: > %pre (and %pretrans in newer rpm versions) has the capability to cancel > out package installation, %preun similarly can cancel uninstall. Doing > so is almost always a terrible idea however, because the scriptlets are > executed at a point where its not possible to cancel other packages. So > when you're using %pre to cancel package installation, you're pulling > the carpet underneath everything else in the same transaction: your > package does not know what other packages might depend on it. So to extend your scenario: A requires B which requires C. C, in the %post, runs stuff which "fails". B's %pre checks for that and then fails. A is now installed anyway, because the transaction isn't resolved when B's %pre fails. ...this is also true if A is an upgrade, so you've taken a working package and broken it by using fake dynamic deps. in %pre Even more fun is to think about the fact that this dynamic dependency in B's %pre is completely unknown to rpm/yum/whatever so they'll be happy to break it when changing the system in any way. And then what do you do when B is upgraded, and both the old and new have the same %pre (failing the upgrade is the worst thing to do here, as it can only cause more damage). To repeat, one more time, yes it's possible to do dynamic dependency checking in the %pre of a package but it's _always_ a bad idea. _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list
