[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: a letter to the rpm dev team:



	Well this mail has got so big that I'll 
have to answer properly when I get home. I did have
work to do today ;)

you'll recieve a mail from scrabble99@canada.com.


Cheers,
		-Tristan

Jeff Johnson wrote:
> 
> On Tue, Mar 04, 2003 at 01:48:11PM -0500, Tristan Van Berkom wrote:
> >       OK this is off to a bad start,
> > Now I really wish I had heard from you last week.
> >
> 
> Sorry, not so bad, at least for me. These problems have been in rpm
> *for years*.
> 
> >
> > > However, there are already 3 or 4 different mechanisms for
> > > reporting errors in rpm. The existing mecahnisms need to
> > > be unified, not augmented with yet another mechanism, imho.
> >
> > IMHO also.
> >
> > > What do you expect to do if there's an error in a scriptlet? There's
> > > no way to guarantee that a failing scriptlet does not have side
> > > effects that cannot be reverted.
> >
> > Hmmm; always more food for thought. (this project for me so far
> > has been "loose ends" ... got to get rid of them loose ends).
> >
> > 1. if a scriptlet has failed in `%pre' logicly; we _dont_
> > proceed to install/erase "this" package.
> 
> Hmmm ignoring %pre error return code needs fixing somewhen, really
> old and stupid behavior in rpm. Unfortunately it's not entirely up
> to me when it comes to changing rpm behavior, but that doesn't stop
> me from telling you how to do it :-)
> 
> >
> > 2. I wont even begin to consider what happens when
> > there's an error while manipulating the FS. (I'll consider
> > for now that that applience will need a new harddrive).
> >
> 
> You should get an error callback through the notify mechanism
> for any syscall failure during payload unpacking. This is overloaded
> ob the cpio failedFile mechanism now present in lib/fsm.c.
> 
> > 3. once the filesystem has been "successfully manipulated"
> > there isn't much of a chance to revert (I keep a backup
> > of the packages that sum up the disto and a backup
> > of "/var/lib/rpm"). If a script fails here; IMHO
> > it would be nice to know about it but not nescisarily
> > suffer from an "insane" database state. i.e. muliple
> > versions existing of the same package.
> >
> 
> There is no "insane" state, there's only a handful of cases
> that need to be dealt with. The database is the easy part,
> figuring out how to gracefully unravel either this file or
> this package or this transaction is trickier.
> 
> Mostly the right thing happens even if there are multiple header
> instances, next upgrade will get rid of all previous duplicates.
> The primary goal of packaging is to deliver bits to the file
> system, database is of 2ndary importance.
> 
> >
> > > And, if all you want is data/text for display on failure,
> >
> > Hmm nope; I want to revert to an older set of rpms if my upgrade
> > goes criticly wrong.
> >
> 
> That's a hard problem, particularly in the face of bad (e.g.
> failing scriptlets) packaging. The operant rule here at Red Hat
> has been to fix the packaging rather than fix rpm.
> 
> OTOH, hard != insoluble.
> 
> > A software distro version (for me) is a list of rpms/versions of
> > packages
> > which should be present. an upgrade can include some older-than-current
> > packages; therefore if I perform an upgrade (lets say 3 newer packages
> > and two older packages and one removed package) it is imperative that
> > I know if it succeeded; succeeding here includes the success of
> > post-uninstall scriptlets.
> >
> > when my upgrade goes wrong _at_all_ I'm going to need to revert.
> > In the case that I revert; I'm doing all that I can to ensure
> > that a stable version (distro) is present on the aplience and
> > in this case I'm going to have to accept scriptlet failures
> > as "non-critical" failures and cross my fingers, hope for the best.
> >
> 
> The cheap and easy solution is to set up a chroot with same packages
> as on appliance and test that your upgrade is functional. That
> reduces the error problem space considerably, removing packaging
> and the rpm state machine almost entirely.
> 
> Not starting is better than reverting, as erased files are simply gone,
> and some of those files may be critical to the operation of reversion.
> 
> > If my revert fails criticly; I still should be able
> > to know this in the scope of my program and possibly
> > do something about it. ("tar -zxf emergency_backup.tgz /" or
> > something like that)
> >
> >
> > > rpmtsRun executes exactly one transaction, so I'm not sure why
> > > you are using the plural. Presumably, you mean that rpm will continue
> > > to install packages from the transaction even if there is a failure.
> >
> >       Ok that just mis-wording. I should say transaction elements.
> > Actually I agree with you 100% that the 2 or 3 bits left in the trans
> > flag
> > bitfield should not be wasted on such a ludicris option. Use
> > of such a dangerous option could result in broker dependencies etc..
> >
> > Yet. In my case; if I know that this transaction will fail for
> > any reason whatsoever: I also know that I will proceed to make
> > a forced transaction that will revert to my previous distro
> > state and then go as far as overwriting the database with
> > the previous one.
> >
> > So in this non-standard utilisation of librpm; such a flag
> > would be of interest.
> >
> 
> You can certainly do whatever you want, including adding transFlags bits.
> 
> What's really needed (imho) is an extensible mechanism that passes
> around the bits opaquely.
> 
> >
> > > there's already
> > > a call back mechanism to report payload unpacking errors that could be
> > > extended. (aside: what really needs to be done is reimplement more general
> > > callbacks, but that ain't gonna happen soon, as up2date/anaconda/yum/...
> > > all rely on the existing API no matter how primitive).
> >
> > This seems to be the ultimate solution.
> > could you be speakin of ts->notify ? I kinda
> > liked the idea of an `rpmps' that can accumulate
> > errors to be analyzed `after-the-fact' but the
> > callback could work just as well. From what I
> > gather, an rpmps ATM only collects errors (or "problems")
> > which can be filtered with the RPMPROB_filter-flags;
> > which does make sense but couldn't really account
> > for everything that "went wrong".
> >
> 
> Yup, ts->notify is the callback, default CLI example in lib/rpminstall.
> Note that the default CLI callback doesn't catch unpacking errors,
> only pushes progress bars.
> 
> 'Twould be nice to get the stupid "void callback()" to return some intelligent
> return code like
>         -1      terminate
>         0       default
>         1       ignore and continue
> or some similar variant. There's more to callbacks than progress bars, sigh.
> 
> > Just for progression's sake I'll assume here that
> > the callback mechanism to which you refer is
> > the ts->notify callback.
> >
> > If I was to go around and attempt to collect all
> > the possible error's standardized under a new
> > type of "rpmCallbackType" and leave everything
> > else "as is"; this shouldn't break the API.
> >
> 
> Don't bother with collecting errors, errno is good enough for the moment.
> 
> Getting some intelligence into the mechanism, like "default/ignore/abort"
> and getting the callback performed on, say, %pre failure, is far more
> important.
> 
> HTH
> 
> 73 de Jeff
> 
> --
> Jeff Johnson    ARS N3NPQ
> jbj@redhat.com (jbj@jbj.org)
> Chapel Hill, NC
> 
> _______________________________________________
> Rpm-list mailing list
> Rpm-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/rpm-list





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []