Yum deltarpm

[Ahmed Kamal]

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 at 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 at 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 at math.unl.edu
> > > <mailto:rdieter at 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 at redhat.com
> > >     <mailto: Fedora-infrastructure-list at redhat.com>
> > >     https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
> > >
> > >
> > >
> > >
> > ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > Fedora-infrastructure-list mailing list
> > > Fedora-infrastructure-list at redhat.com
> > > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20070202/6d07dfa7/attachment.html