On 8/18/05, Dor-Shifer Amit <Amit.Dor-Shifer@xxxxxxxxxxxx> wrote:
>
> Hello,
> I'm failing to re-install a repackaged RPM, which I've relcoted at
> installation:
>
> Here's an attempt I've made:
>
<snip>
> 99 [root/LibertyBell]~ador # rpm -Uvh --oldpackage --relocate
> /users/ador/temp/=$PWD/installation repackage/ADOR_TEST-1.0-T0.i386.rpm
> error: repackage/ADOR_TEST-1.0-T0.i386.rpm: MD5 digest: BAD
> Expected(ce9f6c79bbf1649976b7935cc9a5eb44) !=
> (911976da2eac074ab663c9169ac75b84)
> error: repackage/ADOR_TEST-1.0-T0.i386.rpm cannot be installed
>
>
As you figured out you have to disable the digest checking with
repackaged packages. Sucks, but its by design. When you use the
rollback feature of rpm it does this automatically.
> ..and also when md5 chcksum is disabled
>
>
> 100 [root/LibertyBell]~ador # rpm -Uvh --oldpackage --relocate
> /users/ador/temp/=$PWD/installation repackage/ADOR_TEST-1.0-T0.i386.rpm
> --nodigest
> Preparing... ###########################################
> [100%]
> 1:ADOR_TEST ###########################################
> [100%]
> error: unpacking of archive failed on file ./home/ador/installation/dir:
> cpio: Archive file not in header
> 101 [root/LibertyBell]~ador # cat installation/file1
> this is new file1
>
>
You have stumbled on what I have come realize by staring at the code
far too many times than anyone should (call it an obsession), and that
is there ain't no way that relocated packages will be rolled back
correctly. You have to understand the repackaged package strategy to
understand why this is.
Basically, when you repackage a package it takes the current header in
the database, and all the files that it points to from the filesystem,
and places them into the repackaged package. Before it writes the
header it also removes the INSTALLTID tag and adds a corresponding
REMOVETID tag (and this is where by design, the digests get poisened).
Anyway, its my guess that since it was trying to find the files per
where the header said they would be by default (i.e. with the default
prefix), it did not find them and thus did not repackage them.
This brings up many issues, like:
- Why doesn't rpm keeps some info about where the package has been
relocated? This could be used by the repackage algorithm.
- Why doesn't it throw an error when it can't find a file that's
been repackaged.
- If it does not throw an error then why does it throw one when its
reinstalling
the repackaged package.
But ultimately, if you look at the rpmrollback call (wrong case
probably), you will find that it uses relocations for the entire
transactions, when in actuallity you need the relocations that were
previously used (or do you).
I guess what I am ultimately saying is that rpm transactional rollback
fails miserably if relocations are present, and this is due to issues
in various parts of the algorithm. Ultimately, someone who cares
needs to look at this at some point and make this work in a reasonable
fashion, but I must admit on one level I am not sure exactly what is a
sane policy for rolling back relocated packages (and note a
transaction could have some packages relocated and some not).
Sorry for your pain...james
P.S. See my article for an explanation of the transactional rollback feature:
http://www.linuxjournal.com/article/7034
>
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
