I've been hacking on the code yesterday, and it seems I am hitting some sort of a bug. Basically, what happens is that the plugin starts, does its work, exits, yum tries installing the new rpm, it goes through the "updating" progress bar, then hangs before doing "cleanup" part?!

The thing is, after the hang, all rpm based tools "rpm -q" "rpm -e" "rpm -i" anything, would just sit there stuck! Stracing this, and it is stopped at
futex(0xb7988c3c, FUTEX_WAIT, 1, NULL <unfinished ...>
I did find some bug reports about that

But it should be rare! In my case, this happens everytime. And I have to reboot to clear the lock! I'm probably not releasing the rpmDB lock somehow, anyone faced something similar before ? This is "yum -d 10" output

Running Transaction Test
Member: ImageMagick.i386 0- - u
Adding Package ImageMagick - in mode u
Finished Transaction Test
Transaction Test Succeeded
Member: ImageMagick.i386 0- - u
Adding Package ImageMagick - in mode u
Running Transaction
  Updating  : ImageMagick                  ######################### [1/2]

On 1/18/07, seth vidal <skvidal@linux.duke.edu> wrote:
On Thu, 2007-01-18 at 09:39 -0800, Toshio Kuratomi wrote:
> On Thu, 2007-01-18 at 09:53 +0200, Ahmed Kamal wrote:
> > Appreciating everyone's help, it seems others have attempted this
> > before. Anyway, let's put this through the test of time :) Also, I
> > totally agree with keeping drpms only if they meet certain criteria,
> > i.e. provide >50% savings or similar.
> >
> > Right now, I am trying to figure out how/where the server side will
> > store the drpm metadata. Other.xml.gz seems like a good place, or
> > maybe a new drpm.xml.gz, but I am not sure how such file should be
> > written.
> I seem to recall that primary.xml.gz can list arbitrary xml files which
> the depsolvers will ignore if they don't need them but Seth would know
> better.

repomd.xml can list additional files, not primary - but the result is
the same.

You'd want to tie knowledge of drpms into createrepo.

> Are you writing this from scratch?  If it's using the yum plugin that
> already exists it might be expecting the metadata in a specific format
> already.

plugins can do whatever, pretty much, when it comes to what kind of
metadata they want to deal with.