That rpm DB lock up issue has been resolved with help from the deltarpm package developer. Basically, the code was not freeing the DB transaction. Suse was not facing that issue, as they do not use BDB locking mechanisms.
Now, that this issue was fixed. I've completed a basic prototype of the system. Currently, the yum plugin will detect the user is upgrading a rpm, will download the delta rpm, construct the new rpm, and leave that for yum to install.
On the server side of things (code to generate drpms), I found it very helpful to integrate the drpm generation code into RepoPrune script, as they both share of a lot of functionality. RepoPrune depends on some variables available on fedora servers, which is why I have made a stripped down version so I could use that script on my laptop, but ideally, it should be integrated.
One tiny thing I am facing is the naming convention to be used for the resulting drpms. This name needs to reflect both versions for which this delta was made. I am thinking I need to use something like:
"
name-VerNew-RelNew-VerOld-RelOld.arch.drpm"
Not sure if this would cause any issues, I mean not using the standard rpm naming scheme. But then again, this is not a rpm, which is why I chose suffix .drpm instead of say .delta.rpm
Let me know what you guys think
On 1/25/07, Ahmed Kamal <email.ahmedkamal@googlemail.com
> wrote:Thanks guys, I finally came to the conclusion that the problem was not the python code, but rather the applydeltarpm command that was touching the DB in some wrong way causing it to lockup. I confirmed this by writing a trivial yum plugin that only ran the command using direct on disk files, and yum still hung!
BTW, yes, the constructed rpm does pass all signature checks. I'm currently investigating what's causing the issue inside applydeltarpm.
On 1/25/07,
Matthew Gillen <matt@gillens.us> wrote:
RPM's DB backend gets wedged sometimes. It's become a lot less common than
it used to be, but it just happened to me again recently. A solution (maybe
not the best) is to rebuild the database. I have a script that does the
following:
$ cat fixrpmdb.sh
#!/bin/sh
rm -f /var/lib/rpm/__db*
rpm -vv --rebuilddb
The '-vv' makes it take longer, but I like it so that I can be sure it's
doing something.
Hope that helps,
Matt
Ahmed Kamal wrote:
> that does help, I can clear the lock without rebooting anymore! but, the
> rpm hanging still happens every time. Not sure what's causing the issue
> though.
>
> On 1/24/07, * Rex Dieter* <rdieter@math.unl.edu
> <mailto:
rdieter@math.unl.edu>> wrote:
>
> Ahmed Kamal wrote:
> > I've been hacking on the code yesterday, and it seems I am hitting
> > some sort of a bug.
> ...
> > But it should be rare! In my case, this happens everytime. And I have
> > to reboot to clear the lock!
>
> rm -f /var/lib/rpm/__db.*
> doesn't work?
>
> -- Rex
>
> _______________________________________________
> Fedora-infrastructure-list mailing list
> Fedora-infrastructure-list@redhat.com
> <mailto:
Fedora-infrastructure-list@redhat.com>
> https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Fedora-infrastructure-list mailing list
>
Fedora-infrastructure-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list