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

Re: RPM's that fail in %post...

On Wed, Jan 15, 2003 at 04:15:20PM -0600, Eli Carter wrote:
> I fear I didn't come across as I intended, and I think I just got singed...

Sorry, don't take it personally. I'm having a "bad rpm" day ;-)

> What I was trying to do was ask if there were package managers that 
> lived up to the 'all-or-nothing transaction set installs' criteria, in 
> hopes of gaining some broader perspective on package management.
> I really did not intend to disparage rpm (or your work) in any way.

Many, if not all, package managers will behave badly in "hostile"
environments like ENOSPC, bad packaging, hardware problems.

The reason is quite simple:
	The universe of failures is always bigger than the universe
	of functionality.

More specifically, I would expect failure modes equivalent to rpm's
out of all of apt/dpkg, pkgadd, <your_pkg_manager_here> for the 2 "obvious"
failure modes:
	b) bad packaging like %post failures.
These are hard problems to solve robustly for all possible cases.

In fact, I believe that an rpm transaction can guarantee "all-or-nothing"
behavior by
	a) running all %pre scripts, exit on failure.
	b) installing all payloads with ";12345678" time stamp appended
	to files, headers added to database. Erase, and exit if failure.
	c) Save to be erased files with suffix, renaming installed files
	into place. Undo, exit on failure.
	d) running all %post scripts, Yadda, yadda, on failure.
	e) running %preun, yadda, yadda on failure.
	f) running %postun, yadda, yadda on failure.
	g) removing all erased files, all erased headers.

Unfortunately, the above state machine is *not* rpm's state machine.

(aside) It could be, i.e. there's no specific guarantee that would
prevent all %pre's from being run before payloads were installed, there's
no gurantee that files can't be installed with suffixes, etc, etc.

However I seriously question whether the effort involved in implementing
a always reversible package apply/commit transaction methodolgy
is worth the effort. It's *much* easier (and hence more robust) to just
run a list of what used to be installed, and then restore -- from original
packaging -- the software that was previously installed.

> That reminds me, I need to bugzilla the scrambled eggs.  RPM doesn't get 
> them cooked quite the way I like 'em.  Though I guess I'll wait on 
> adding 'nice, crispy bacon' for now... ;)

Hey, I almost added a --pooper-scooper popt alias yesterday after
someone's pet left a (ahem) "package" in the building.

I'm gonna need to work on the hot bacon grease spatter guard, please bugzilla.

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] []