I am attaching a patch for the icc ebuild that removes the dependency to rpm and adds one to rpm2targz. It also changes the ebuild to work with the different tool.
Created attachment 13600 [details, diff] icc-norpm.diff makes icc depend on rpm2targz instead of rpm
Created attachment 13602 [details, diff] icc-norpm.diff an easier to apply version of the patch (changed the header only)... the first one did not apply easily
Please see: http://www.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=slrnavcfu5.4ns.avenj%40cerberus.localhost And: http://bugs.gentoo.org/show_bug.cgi?id=11211 Short summary: I was going to do the same thing, but rpm2targz is up to 10x times slower, possibly more. The RPM dependency sucks, but a decently large number of people already have RPM installed after merging packages like KDE, so I'm going to stick with rpm2cpio in the ebuild.
*** Bug 23180 has been marked as a duplicate of this bug. ***
I checked the links. Yes, I agree that rpm2targz might be even 100 times slower that rpm, because what it does is to: 1. extract the files from the rpm file 2. tar the files up 3. gzip -9 the files However, it seems that nobody even cared to look inside the patch I suggested. My suggestion does not use rpm2targz. It only uses rpmoffset from the rpm2targz package. It simply uncompresses the files and I believe it might even be faster than rpm itself. Could someone who has installed rpm try to give us the timings of: f=somebigrpm.rpm 1. time rpm $f (whatever the command to extract files using rpm is) 2. time sh -c "dd ibs=`rpmoffset < $f` skip=1 if=$f | gzip -dc | cpio --extract --make-directories --unconditional" I should maybe mention that number 2 was my suggestion.
Sorry, I looked at the summary and went with that. I'll take a look at this.
Zadeh, could you take a look at this at some point?
Your comment regarding the speed of rpm2targz brought a very interesting issue up. I therefore submitted bug #23249. Something I did not understand though is: "a decently large number of people already have RPM installed after merging packages like KDE" I just tried "emerge -pv kde", and it did not ask me to install rpm. I do not have neither kde nor rpm installed.
One of the KDE packages does or did depend on RPM. That must've changed recently.
The source for rpmoffset.c is so short and simple though should just modify it to do this directly... it wouldn't be too hard. Also instead of reading in chunks up to the end marker, imo it should probably try to get the file size via [f]stat() and read from the tail end, which would be faster. Could also make an rpmextract eclass based on whats happening here... Looks like some other ebuilds are using the rpmoffset -> gzip -> cpio thing already. Btw is the goal to save compile time with rpm or is it an "rpm sucks" thing? :)
The rpm tarball is currently 8.3M. I bet it takes a long time to compile which would have been OK, if it were at least remotely useful. So, no, rpm does not "suck", but compiling rpm to only use rpm2cpio does. What do people who have emerged rpm use it for anyway? I can think of a single possible use. Also, there is an rpm.eclass in portage since today. Seems it is currently using the slow rpm2targz method though.
well, for what its worth. i just committed a new rpm.eclass that uses the direct pipe through instead of rpm2targz. basically, it just lifts the code out of rpm2targz. in addition to that, in rpm_unpack() it will see if rpm2cpio is around and use that instead. see comments in the eclass on why that might be desirable.
Created attachment 16499 [details, diff] icc-7.1.006.diff Makes the icc ebuild use rpm.eclass for unpacking. Removes the executable bit from a bunch of files (headers, docs, .a files)
I closed this earlier, but bugzilla stabbed itself in the meantime. Committed - thanks much, guys :)
Jon, could take a peek at bug #23180 as well? It is marked as a duplicate to this one, but it regards ifc. There is a patch in there that needs to be applied.
