Bugzilla Bug 23179

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 an attachment (id=13600) [edit]
icc-norpm.diff

makes icc depend on rpm2targz instead of rpm

Created an attachment (id=13602) [edit]
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 an attachment (id=16499) [edit]
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.