[Yum-devel] clean up sooner

[seth vidal]

On Mon, 2006-02-20 at 13:40 -0500, Dennis Gregorovic wrote:
> On Mon, 2006-02-20 at 10:45 -0500, seth vidal wrote:
> > > I spent time this weekend reading up on the Python RPM bindings and
> > > after some experimenting I think I know what it will take to add the
> > > transaction logging functionality.  
> > 
> > What I had talked about earlier was just:
> > 1. iterate ts/tsInfo and build up the file
> > 2. add items into the rpm transaction callback to remove/mark the items
> > as complete as they occur
> > 
> > What else were you thinking of doing?
> 
> Yup, that's about it.  I just didn't know the particulars before (e.g.
> how to iterate over a db transaction and pull out transaction type plus
> RPM file location).  
> 
> We may also want to add a config option for where the transaction logs
> are stored.  I was thinking of "transaction-logdir", with a default
> of /var/log/yum-transactions.

that's fine - but keep with the convention of _'s for name separation -
if for no other reason than consistency.

> -> > Unfortunately, it looks like we are
> > > currently blocked on a bug in the Python bindings that was fixed in RPM
> > > 4.4.3 (Rawhide is on 4.4.2).  I've filed a bug requesting inclusion of
> > > the patch: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182063
> > > 
> > > David, your reasons for a flat-file approach sound good.  I'll try to
> > > put together a patch this week.
> > 
> > Why do you need that patch? You should be able to do that without the
> > Key() functionality - moreover when was Key() added to the ts bindings?
> > I'd rather us not get too bound up needing rpm > 4.4 if only b/c it
> > makes it harder to use things on older distros with requirements like
> > that.
> 
> I was using the Key() functionality to determine the location of the RPM
> file that's scheduled to be installed.  However, now that I think about
> it, we already have that data in tsInfo, right?  In that case, maybe
> Key() isn't needed after all.

I'd think you'd want to store:
  what action and then the package naevr + repo (or 'installed') for
each item

You'll need to make sure you break apart each update into install+erase
and each obsolete into install/update + erase so that we have every one
of the actions accounted for.

It's the clean up actions which started all of this, of course.

-sv