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

Re: rpm rollback features...



On Wed, Jul 17, 2002 at 10:02:48AM -0500, James Olin Oden wrote:
> First let me deal with the issue of terms for the sake of precision
> of meaning (and to make Socrates smile (-;).  Hence forth:
> 
> 	"system install" refers to the initial install of rpms on a 
> 		system before any rpms have been installed on the 
> 		system.
> 	"system upgrade" refers to the addition of rpms any point 
> 		after system install.
> 	"rpm install" refers to the installation of an rpm on the 
> 		system when that rpm is not installed currently.
> 	"rpm upgrade" refers to the upgrade of a single rpm that
> 		presently exists on the system.
> 
> Not trying to be pedantic, just trying to assure what I mean is 
> properly conveyed and confusion is held to a minimum.
> 

The ambiguous definition is "upgrade", which means both install/erasure,
or even install only, if context is upgrading to a new distro version.

> > 
> > Yup. The current implementation will only rollback upgrades, not installs,
> > to avoid the problem of accidentally cleaning your disk by typing
> > 
> > 	rpm -Uvh --rollback "20 years ago"
> > 
> > I'll be happy to show you how to eliminate the safety check if/when the
> > time comes.
> >
> Actually, I want the saftey check but with an exception.  I want rpm 
> at "system installation" to mark the set of RPM's that were installed then
> to be part of the original system install.  RPM can know that it is 
> system install, because no RPM's have been added to its database yet 
> (or this is how I understand things?).  Ever there after, any "rpm install" 
> is known to be part of a "system upgrade" as it was not part of the
> "system install".  So when a rollback is requested to a time before
> a particular package did not exist on that system, if the package was
> not part of the "system install", and thus part of the "system upgrade" 
> the package can now be removed.    If on the other hand the package
> was part of the "system install" it would not be removed.
> 

OK. Since every package has an install transaction ID (TID, read: time stamp),
you would like to see a safety check that prevents any package with
the earliest existing transaction ID from being erased with --rollback. FWIW,
finding the earliest TID and preventing a rollback iff all the elements
in the transaction have the earliest (or more generally, any specified)
time stamp won't be hard to implement in rpm --rollback.

That's mostly a sensible policy, but may have some head-scratching
consequences when deployed in the Real World, if, for no other reason,
time stamps (or any other integer used to order) often get incorrect
values for whatever reason. Any policy is only as good as the data
which it's given.

No matter what, disaster avoidance policies are gonna be needed with
--rollback, whether (as currently implemented)
	No rollbacks composed only of package erasures.
or
	Initially installed packages cannot be rolled back.
or
	These packages will never be erased.
or
	...

Another point which needs to be thought through is transaction vs.
package rollback. Since a TID is used both to
	a) order transaction level operations.
	b) specify set membership in a particular transaction.
the Right Thing mostly happens when, say, a package within a given
transaction has been manually removed before attempting --rollback.

There are most certainly other difficulties merging manual and automated
package management, not the least of which is that --rollback is
impossible if --repackage was not performed when upgrading.

> Essentially, I don't want an all or nothing approach.  I like that RPM checks
> to make sure the packages don't get removed that shouldn't, I just want it
> to qualify the criteria which it use.  Again, maybe I am wrong for wanting 
> this in RPM itself; I make no claims to fully understanding this problem space
> only that I am trying to reach certain goals within it (but without
> destroying the things that did not show up on my radar screen as important).
> At first glance though, allowing RPM to have some perception of "system install"
> versus "system upgrade" such that it could allow for intelligent removal
> of packages on a rollback does seem to be a good thing.
> 

The needs are understood, but devising simple/coherent/implementable policies
is sometimes tricky. As I said privately, I believe that transaction rollbacks
require disciplined system administration, and tools that assist in enforcing
policies, that may not exist (yet) for humans typing on the command line.
rpm has only the mechanism of --repackage/--rollback, but may very well need
to enforce the rollback policy mechanism as well.

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