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;000000fa”. 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.
> # 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.
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
73 de Jeff
Received on Tue Dec 22 16:32:35 2009