On Sat, Jul 31, 2004 at 09:41:11AM -0400, James Olin Oden wrote: > On Wed, 28 Jul 2004, Jeff Johnson wrote: > > > On Wed, Jul 28, 2004 at 09:15:20AM -0500, David D. Hagood wrote: > > > I am trying to use the rollback ability of RPM, but I would like to convert > > > the files that are created by RPM into "full" RPMs - currently they do not > > > seem to be full RPMs as they are missing header information. What > > > steps/tools are needed to make a rollback RPM into a full RPM? > > > > > > > No conversion is possibly in general, as a --repackage is "best effort", > > there can and will be missing files, changed permissions, more. > > > > Go find the original packacge is my recommendation. > > > Jeff, changed files work fine when re-installing from repackaged packages, > but there are two issues can become problematic. One is that if you > repackage a package that has missing non-config files, when you try to > re-install it (i.e. via --rollback or my autorollback), the psm will get > to the point where files are delivered, and soon as the fsm sees that a > file is missing from the archive it fails delivering the rest of the > files in that package. I mean to do something about this at some > point, but I figured I would mention it. What I do now is check for > missing files before doing a system upgrade which mostly catches this > situation. > Prolly. Bugzilla, please, almost certainly a 3 line fix in lib/fsm.c. > The other thing, that I have no idea how to fix (the other I have > ideas no matter how half baked), is that after a repackaged package is > put in the database (at least from my autorollback code paths...don't > know if it happens with --rollback), then the next time you run an > rpm transaction and try to upgrade that package (or remove it), then > rpm fails when checking the digest for the header of the package in the > db. Last time I was mucking around with autorollback stuff, I tried > something silly like uncommenting the lines you had commented out to > remove the REMOVETID tag from the header when puting the package back > in, but that just generated segfaults. My thinking was that since it was > really the REMOVETID that poisened the digests that removing might > undo this. Anyway, I don't when next I will be looking at this again, but > if you had any ideas on what I could do basically make the digests right > in the repackaged packages header when it was put back in the db I would > apreciate your in sight. > Yup, rolling back an already rolled back package doesn't do the right thing. It's not just REMOVETID, it's any appended tags on the header. Avoidance by refusing to rollback packages that have REMOVETID one approach, another is to extract the original header blob. Bugzilla, please. 73 de Jeff -- Jeff Johnson ARS N3NPQ jbj@xxxxxxxxxx (jbj@xxxxxxx) Chapel Hill, NC _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
