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 <a href="https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145021">https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145021</a> <a href="http://lists.centos.org/pipermail/centos-devel/2005-June/001890.html"> http://lists.centos.org/pipermail/centos-devel/2005-June/001890.html</a> 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-6.2.8.0-3.fc6.1 - u Adding Package ImageMagick - 6.2.8.0-3.fc6.1.i386 in mode u Finished Transaction Test Transaction Test Succeeded Member: ImageMagick.i386 0-6.2.8.0-3.fc6.1 - u Adding Package ImageMagick - 6.2.8.0-3.fc6.1.i386 in mode u Running Transaction Updating : ImageMagick ######################### [1/2] <div> On 1/18/07, seth vidal <<a href="mailto:skvidal@linux.duke.edu">skvidal@linux.duke.edu</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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. -sv </blockquote></div>