On Feb 13, 2012, at 7:15 PM, PuttaReddy Challa wrote:
> There are no lib*.so.* files included in the RPM pkg. The following is the list of files when not INCLUDED in the RPM, rpm install works without issues.
> These are around 460 MB before adding these files the RPM size is about 3.6GB once these are added it is coming around 4.2 GB.
The limit is the largest integer that fits in 32 bits:
Note that there may be certain places where the sign bit is used, where the limit is
But you have already shown that that the sign bit isn't used
on the unpacking code path because your previous pkg was 3.6Gb.
> I would like to know what the max size of the RPM that i can create/install on RH AS 32 without issues.
> rpm -q -filesbypkg -p TESTpatch-220.127.116.1101.0-0.noarch.rpm | grep -i TESThttpsProxy
> TESTpatch /opt/TESTare/patch/TESTpatch/Linux/3AS/TESThttpsProxy-18.104.22.168.20.6-1.tar.gz
> TESTpatch /opt/TESTare/patch/TESTpatch/Linux/4AS-X86_64/TESThttpsProxy-22.214.171.124.20.1-1.tar.gz
> TESTpatch /opt/TESTare/patch/TESTpatch/Linux/4AS/TESThttpsProxy-126.96.36.199.20.0-1.tar.gz
> TESTpatch /opt/TESTare/patch/TESTpatch/Linux/5SERVER-X86_64/TESThttpsProxy-188.8.131.52.20.4-1.tar.gz
> TESTpatch /opt/TESTare/patch/TESTpatch/Linux/TESThttpsProxy-184.108.40.206.20.6-1.tar.gz
> TESTpatch /opt/TESTare/patch/TESTpatch/Linux/SLES-10-X86_64/TESThttpsProxy-220.127.116.11.20.2-1.tar.gz
> TESTpatch /opt/TESTare/patch/TESTpatch/SunOS/5.10/TESThttpsProxy-18.104.22.168.20.7-1.tar.gz
> TESTpatch /opt/TESTare/patch/TESTpatch/SunOS/5.8/TESThttpsProxy-22.214.171.124.20.5-1.tar.gz
> TESTpatch /opt/TESTare/patch/TESTpatch/SunOS/5.9/TESThttpsProxy-126.96.36.199.20.3-1.tar.gz
> TESTpatch /opt/TESTare/patch/TESTpatch/SunOS/TESThttpsProxy-188.8.131.52.20.7-1.tar.gz
So your issue is the size of your package.
My guess about pre linking is/was a known problem: what I missed
was the size of the *.rpm package you are producing.
In fact, you now have the record for the largest known *.rpm package ever attempted
using rpm-4.3 and older.
The previous record was held by Nils Philippsen @redhat.com with an Oracle database.
(and apologies for the humor ;-)
Split the package into two packages is the easiest path forward.
73 de Jeff
Received on Tue Feb 14 01:31:45 2012