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

Re: a letter to the rpm dev team:

	OK this is off to a bad start,
Now I really wish I had heard from you last week.

> 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.

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).

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.

> 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. 

A software distro version (for me) is a list of rpms/versions of
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.

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
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.

> 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".

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.

Anyhow; let me know what you think.

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