I may even see if I can work up a patch for rpm to at least have it refuse to build broken srpms:).The installation of such packages then failed with a Digest mismatch error.Now, rpm no longer allows the creation of such packages, which in turn prevents the described installation failure.I have a src rpm I created a while ago on a Redhat 6.0 system which fails to install on a Redhat 6.2 system.
Version-Release number of selected component (if applicable). This worked on RHEL 6.0. Of note here is that the SRC RPM is 4.8 GB big. Afaik rpm uses its own implementation of cpio, so it is possible that it was broken for large files at the time of the RHEL-6.0 - and unpacking it directly via cpio just fails - as the file is probably incomplete or incompatible with original cpio format. Since a previously working src.rpm fails to install (well, extract) on rhel-6.2 itd seem that the payload gets truncated on extract phase (as opposed to creation), for whatever reason. OK, sorry, I naively assumed that rpm used cpio to create and extract rpms. Nonetheless, there is something that has changed to break both cpio and rpm. I cant check that as I no longer have any 6.0 machines alas. So, I dont think its particularly something to do with a RHEL 6.0 - 6.2 compatibility, as things are broking consistently within 6.2. Thats actually larger than rpm can currently support, the limit for single file in a package is UINT32MAX bytes (due to the underlying cpio format limitation). This is checked for files in binary packages but source packages get generated a bit differently and that check, along with various other large package aspects is missing for src.rpms:-. So the actual bug here is that rpm shouldve never allowed packaging that thing in the first place, and failure to installextract is in fact expected. The uint32t type used for file sizes gets truncated or wraps around at build-time, causing installextract to see a shorter file than it is and things go downhill from there. I fail to see how the src.rpm couldve been successfully installed on rhel-6.0. Perhaps you never actually installed the src.rpm on rhel-6.0 either, only (re)built from a spec. Neither of which is going to directly fix your issue (the cpio format limit will almost certainly not be fixed in rhel-6 or even -7), but its possible to work around it by splitting the sources into max 4GB pieces. And Failed Duplicate Permission Archive Sizes AndThat will probably work even now, although there will be anomalies with reported total archive sizes and such. It would be nice to see those enhancements land in RPM at some point though - the use case here is deploying a proprietory program (Matlab) as an RPM by simply bundling the whole thing up, and running the matlab installer in install. And Failed Duplicate Permission Software Like ThisBeing able to deply binary software like this as an rpm is a great help when deploying many machines using tooling that makes use of yum repos (katello, pulp, foreman etc). Back when I was on RHEL 6.0 I was building the SRPM and then successfully generating binary rpms from that SRPM using mock. The newest matlab is 4.8 GB, perhaps the old one was less than 4.0 GB. Still, I wonder why it wont unpack on 6.2, when it seemed to be doing so on 6.0. Anyway, will check more carefully and see if i can make sense of it.
0 Comments
Leave a Reply. |