On Tue, Jan 27, 2004 at 03:29:41PM +0000, Adam Spiers wrote:
> Jeff Johnson (jbj@xxxxxxxxxx) 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.
>
> That's an interesting POV. In that case I'd say rpm has outgrown its
> original design - there are many rpms out in the wild with little or
> no QA. I can see how Red Hat could take the "not our problem" stance
> on that though.
>
Yah, mon, these bits were never intended for the rock'n-roll that
is currently going on.
Still, the rpm bits *were* designed to make install into a chroot
trivial for QA purposes. There is absolutely nothing wrong with
that design decision, i.e. test before you release.
> > 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 - it's not possible to achieve a 100% recovery; however there
> is the potential for a best effort recovery, and that grey area is
> more or less what we're discussing here.
>
And so we move to definition of "best effort", your (and James Olin Odin's)
definition are different than others. My own answer is
Patches cheerfully accepted.
as always.
Yes it sometimnes takes a while to get the patch integrated, sorry James ;-)
The universe of errors is far, far larger than the universe of fiunctionality.
> Finally, I'd always thought of %pre as (partially, at least) an rpm's
> chance to declare itself unsuitable for installing via a deliberate
> non-zero exit code. Would you say that's a misplaced belief?
>
I am not in a position to judge anyone's belief of what the intended
purpose of %pre is or was. From my POV, %pre is a step in a rather
simple state machine that has well defined inputs and well defined
outputs.
What is creepy is that rpm has always treated error returns from
%pre a little differently, basically because it's necessary to
ignore certain errors while trying to get a distro release together.
Changing that wartlet is non-trivial, as
This used to work!
noise is predictably deafening.
73 de
--
Jeff Johnson ARS N3NPQ
jbj@xxxxxxxxxx (jbj@xxxxxxx)
Chapel Hill, NC
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
