On Dec 22, 2009, at 6:43 AM, Manoj Palhade wrote:
Dear RPM Team,
I am doing Performance testing of RPM on My Target (QNX as an OS). I am
trying to install RPM Package of size 100 MB. This RPM Package contains zip
file of 100 MB. Time taken by RPM to install this 100 MB package is 3.10s;
which I believe is wrong for 100 MB rpm package. I haven’t seen Zip file got
copied after installation. I found following file at destination location
“Test100.zip;00fa”. I tried to remove this file but I am not able to
remove it.
All upgrade operations haev a 32 bit transaction id.
Files installed during a transaction are first created with the transaction
id suffixed and then renamed into place.
There's no reason I know of why you should not have been able to remove the
file.
I tried same Testing in VMWare Session where QNX is installed; it is working
file. I can see zip file of RPM Package getting copied.
Is there any limitation on size of RPM Packages and File inside the RPM
Packages.
There are limits on both package and file size imposed by 32 bits used
to store the size. The 32bit integter is unsigned, so 4Gb should be the
limit. Internally, rpm uses a 64bit integer for file/package sizes, so
legacy compatibility when saving file/package sizes is the main
reason for the limitation. E.g. cpio cannot represent files 4Gb ...
Another problem I am getting as follow.
I am getting following error when I try to un-nstall RPM Packages
error: cannot create %_repackage_dir /opt/sys/var/spool/repackage/88817
Some element in that path does not exist. Likely /opt/var/spool/repackages.
You can eith create the directory, or disable re-packaging.
To disable, undefine (or set to 0) this macro
# If non-zero, all erasures will be automagically repackaged.
%_repackage_all_erasures1
# rpm -e Test25-1.0-1
error: cannot create %_repackage_dir /opt/sys/var/spool/repackage/1430
# rpm -e Test20-1.0-1
error: cannot create %_repackage_dir /opt/sys/var/spool/repackage/1445
Last folder name (88817) varies each time. How to avoid this error. Is this
error is because of Fat16 file system.
Yes the last number is the transaction id, and will be different for every
transaction.
(aside)
The transaction id is a time stamp, seconds since the epoch. You really should
set your clock correctly; other wise transaction id's based on system time will
be
meaningless.
73 de Jeff
