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

Re: a letter to the rpm dev team:

On Fri, Feb 28, 2003 at 12:05:49PM -0500, Tristan Van Berkom wrote:
> Good morning everyone!
> 	Its me again; my automatic software updater
> is almost rock solid. There is just one or two
> problems that I have that logicly shouldn't be
> or can't be fixed outside librpm.
> 	I'm going to lunch and then after that
> I'll make theese changes (this could take me 15 min.
> or it could take me an hour or two to do it *well*).
> My boss might tell me otherwise but I'm prepared 
> to spend an extra hour or two on this if you 
> are interested in the changes I'll make and/or have 
> opinions on how to proceed.
> 	1. when rpmtsRun() returns `-1' I have no
> 	clue as to why. (prescript ? opendb ? install ? post ?...)

rpmtsRun() returns -1 only under exceptional "can't happen" conditions.

> 	2. unless I construct my own loop and create
> 	single no-dep transactions; librpm will continue
> 	to execute transactions after one or more have failed.

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.

Yes, continuation is the best policy for an installer that is expected
to "just work". Why crap out and force a support issue when many, many, many
errors due to broken packaging have limited scope and can be fixed
through other means after the install?

> I am proceeding to work around #1 right now in 

Something else is wrong. Diagnose before working around.

> transactions.c/psm.c (so at least I know that
> the failure was due to a post/pre[un]install script).
> I'm thinking of going with something like
> rpmSetErrorCode(REASON) method.
> And as for #2, I was thinking of adding a
> `transaction' flag that would mean in effect
> (not sure if it should look more like
> would take alot more effort for a little
> more logic/readability).

Careful, there are only a few unused bits in transFlags.

73 de Jeff

Jeff Johnson	ARS N3NPQ
jbj@redhat.com (jbj@jbj.org)
Chapel Hill, NC

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