2008-03-05move razor_set_diff so it's not in the middle of the transaction code
Dan Winship <danw@gnome.org> [Wed, 05 Mar 2008 19:01:51 -0500] rev 146
move razor_set_diff so it's not in the middle of the transaction code

2008-03-05clean up packages states some
Dan Winship <danw@gnome.org> [Wed, 05 Mar 2008 10:46:40 -0500] rev 145
clean up packages states some

2008-03-04checkpoint, misc rewritage
Dan Winship <danw@gnome.org> [Tue, 04 Mar 2008 19:07:14 -0500] rev 144
checkpoint, misc rewritage

2008-03-04Fix version handling (particularly wrt epoch) on import
Dan Winship <danw@gnome.org> [Tue, 04 Mar 2008 10:55:01 -0500] rev 143
Fix version handling (particularly wrt epoch) on import

2008-03-03unduplicate file-finding code
Dan Winship <danw@gnome.org> [Mon, 03 Mar 2008 16:19:56 -0500] rev 142
unduplicate file-finding code

2008-03-03add struct razor_transaction_resolver to reduce redundant procedure args
Dan Winship <danw@gnome.org> [Mon, 03 Mar 2008 16:05:33 -0500] rev 141
add struct razor_transaction_resolver to reduce redundant procedure args

2008-03-03redo some of the transaction code, get conflicts and obsoletes partly working
Dan Winship <danw@gnome.org> [Mon, 03 Mar 2008 14:55:16 -0500] rev 140
redo some of the transaction code, get conflicts and obsoletes partly working

now uses a bit array of to-be-installed/removed packages and uses that to
avoid needing to do either per-property searches or repeated merges. but it
really needs to have a bit array of properties too probably

checkpoint before starting on simplifying/cleaning up the existing
transaction code

2008-02-29add somewhat inefficient file dep removal code
Dan Winship <danw@gnome.org> [Fri, 29 Feb 2008 15:09:44 -0500] rev 139
add somewhat inefficient file dep removal code

(fwiw, the comment on the previous commit was incorrect)

2008-02-29implement file dependencies for installs
Dan Winship <danw@gnome.org> [Fri, 29 Feb 2008 12:45:08 -0500] rev 138
implement file dependencies for installs

removes are trickier because there are no backlinks from the files array
the properties array, so there's currently no way to efficiently determine
what packages are affected by the removal of a particular file

2008-02-29Redo updates and removes in terms of a single razor_transaction abstraction
Dan Winship <danw@gnome.org> [Fri, 29 Feb 2008 11:53:15 -0500] rev 137
Redo updates and removes in terms of a single razor_transaction abstraction

Also does versioned depsolving at least partially.
Update main.c and test-driver.c for that, and fix some unrelated test-driver
bugs.

Now gets up to testUpdateSinglePackageObsoletesOldRequirement, although
it really should not be passing the multilib tests; apparently they aren't
clever enough in their testing of the depsolving algorithm and are allowing
it to come up with the right answer for the wrong reason.