I'm currently trying to create an ebuild for a binary app which is shipped as a bunch of .rpms inside a huge .tar.gz. The problem is that rpm_unpack() cds to $WORKDIR before it unpacks/unwraps the .rpms. In this case all files are directly inside the .rpm (without any subdirs) so I end with a totally cluttered $WORKDIR and its impossible to separate the unwrapped stuff from the formely unpacked things. I kludge around this via calling 'WORKDIR=$PWD rpm_unpack $rpm' but that's not too beautiful. From rpm_src_unpack()'s POV rpm_unpack() shouldn't need to cd anywhere as that's already done in the calling function. I don't know if any other ebuild relies on this behaviour though.
liquidx - I agree with this change. I think rpm_unpack should be modified to not cd before unpacking the rpm since rpm_src_unpack already does it. There's a couple of places in the portage tree that would need to be verified/modified for this to work, but rpm_unpack should be a more general unpack routine so it can be more easily used with some of the ugly cases for rpms we find in the wild.
as long as the change doesn't impact existing ebuilds, then i have no problems with it ..
i've look at all the ebuilds that use rpm_unpack, and here is a list of ones which may extract stuff into the wrong place if cd ${WORKDIR} gets removed from rpm_unpack() media-gfx/maya dev-lang/icc yes, thats it. the only change in those packages is to make sure they have moved back to ${WORKDIR} before running rpm_unpack as a transition so that when the corrected rpm.eclass is in portage, they won't break. then when the rpm.eclass is in portage, they can do whatever they want since rpm_unpack will not be issuing 'cd' any more.
i've verified that icc unpacks correctly with the new changes since the 7.x series has S=${WORKDIR} and also 8.x has a mv instruction that just fails, but the rpm is unpacked properly without the mv anymore. maya i only checked visually, but also in this case ${S} and ${WORKDIR} is the same, so there shouldn't be any impact. so finally i can close this bug. committed new rpm.eclass to portage.
