On Tue, 27 Jan 2004, Jeff Johnson wrote: > On Mon, Jan 26, 2004 at 06:50:24PM +0000, Adam Spiers wrote: > > > > I'm not sure I understand where Jeff was going with his suggestion of > > actions being based on the result of %post success however. I had > > always envisaged the semantics of %post being "try to finish up > > cleanly by running %post, but if it fails, we consider it an > > unfortunate partial success rather than a failure which then gets > > rolled back". If %post succeeding is to be considered a strict > > requirement for success, then rpm should be more diligent about > > cleaning up from its failure. > > > > Depends on POV. rpm was designed as an installer library, not as > a general purpose software manager. Within that narrow "installer > library" design, failures, particularly scriptlet failures, are > not supposed to happen, that's what package QA is supposed to > identify and fix long before the installer sees the package. > Again, Jeff, I completly agree that they should not happen, but they can and do happen. Is this a sign that ones QA process needs to be fixed; probably, but then again I have never seen a perfect QA process (-; I am pretty sure for instance that RedHat packages are tested in upgradde and install scenarios but not in a rollback scenario (mainly because from time to time I have seen them fail on a rollback (not and autorollback) in some pretty interesting ways, thus leading me to such a conclusion). As I was saying in the previous post, at least to some degree, I want an installer library that supports the mechanisms needed to implement various policies centered around undoing bad transactions. In some cases a bad transaction is deemed to be bad not because there was any failure in any packages, but simply the new software load was decided to be undesirable. This instance is covered by RPM's rollback feature. In the other case the transaction is deemed to be bad because there was a package failure (%pre, %files, %post, %preun, %files, %postun, and lets not forget triggers (-;). The autorollback patch is comming close to providing a mechanism to satisfy my policy requirements in this case. > It's really not that hard to check package quality by installing > in a chroot. It's simply not possible to recover from all possible > errors, nor even a significant subset of all possible errors. > Agreed, but I am required to try (-; Cheers...james > 73 de Jeff > > > > > _______________________________________________ > > Rpm-list mailing li > > Rpm-list@xxxxxxxxxx > > https://www.redhat.com/mailman/listinfo/rpm-list > > _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
