[Yum-devel] clean up sooner

seth vidal skvidal at linux.duke.edu
Tue Feb 21 05:07:58 UTC 2006


On Mon, 2006-02-20 at 12:38 -0800, David Lutterkort wrote:
> On Mon, 2006-02-20 at 10:48 -0500, seth vidal wrote:
> > > I don't think there's anything wrong with using a sqlite DB, but it
> > > might be simpler to just use flat files: before actually starting the
> > > transaction, write out what needs to be done into a file in a format
> > > that is convenient to parse back in. 
> > 
> > xml. No point in maintaining N file formats just for fun, if we don't
> > have to.
> 
> It's a new file format either way. Do you think that XML is needed
> because the structure of the file will require nontrivial parsing or
> that these files might be interesting to other programs ? Also, XML is
> not suited for writing out data where the stream could be interrupted at
> any moment; if yum crashes half way through writing, the XML is not
> well-formed.

fair enough - but that's true of any text format, isn't it?
who knows when the write will die?




> The only difference between your and my approach is when you do the work
> you describe above - during the transaction or when yum starts. With
> files, you can avoid parsing the file altogether if you maintain a
> separate lockfile during the transaction and delete it afterwards.

So you'd be maintaining two files, one of them simply as a lock file -
which can also be done how I was describing, can't it?


> What percentage of yum transactions do you think fail ? In my
> experience, it's certainly less than 10% of the uses.

right but I bet your experience is one of good bandwidth and reliable
machines. :)


> 
> > I'm curious if writing out an sqlite db is that much less cheap for this
> > little an amount of data.
> 
> Only profiling can tell us that; though I would assume that there is
> some nontrivial startup cost for any sqlite DB.

not much - have you ever used sqlite?

> 
> > > If you use one file per transaction, you could even keep them around as
> > > an audit log of what yum did on a given system, and people could simply
> > > truncate the logs with an appropriate tmpwatch job. That kinda thing is
> > > a little more hairy if you use a DB.
> > 
> > You can do the same with a sqlite db per transaction, too.
> 
> But you have to write special-purpose code to let the user indicate how
> much of an audit log to keep - with tmpwatch it's a small configfile,
> that gives the user a lot of flexibility in describing how much to keep.

I'm talking about using tmpwatch.

sqlite is just a db in a file.

so you make one per transaction and use tmpwatch the exact same way you
were describing.

-sv





More information about the Yum-devel mailing list