Hi, the initial author of the googleearth ebuild(on CC) inspired me to add support to unpack even files that are not in DISTDIR but have no realtive path. It is simple and backwards-compatible. second part is unification, ${srcdir}/${x} -> ${srcdir}${x} everywhere. third part is support for makeself-generated .bin, .sh and .run files. It is majorly copied from eutils.eclass. See grep "unpack_makeself" /usr/portage/games-*/*/*.ebuild for current useage. I think it should be done in ebuild.sh to allow it to be used more widely. Does not break any non-Makeself bin|sh|run - it just vecho's there. It only dies when it has detected a Makeself bin|sh|run and is unable to unpack it.
Created attachment 89170 [details, diff] unpack-add-makeself.patch
(In reply to comment #0) > third part is support for makeself-generated .bin, .sh and .run files. It is > majorly copied from eutils.eclass. See > grep "unpack_makeself" /usr/portage/games-*/*/*.ebuild for current useage. I > think it should be done in ebuild.sh to allow it to be used more widely. I'd rather not include makeself support in ebuild.sh. What's wrong with using eutils for that? My inclination is that portage internals should be more minimal, with support for extensibility via things such as eclasses and profile.bashrcs.
(In reply to comment #0) > to unpack even files that are not in DISTDIR but have no realtive path. Why would you want to unpack a file with an absolute path?
Created attachment 89451 [details, diff] unpack.patch New patch - uses app-arch/unmakeself, adds rpm support(copied from rpm.eclass), adds TAR support.
What's the best way to unpack files from an archive, which was one of the files unpacked from an archive in ${A}, into a specific directory? It would just be nice if there was an easier way than this: unpack ${A} cd "${S}" mkdir data cd data unpack ./../data.tar
I'm with Zac on this one, we should rather move the unpack code (together with most of the helpers and some other stuff) into the tree.
yeah, i think rpm and makeself support is good where it is (rpm.eclass / eutils.eclass) also, unmakeself isnt even in the tree ...
I'm very much for the very first part of this patch (the ability to unpack from absolute locations). The biggest reason for this is for the installation of files from CD locations. cdrom_get_cds from eutils lets you form an absolute (but not predictable in a relative manner) path to the file to unpack. It'd be much nicer to do: unpack ${CD_ROOT}/${TARBALL} than to do the rather dirty: cd ${WORKDIR} cp ${CD_ROOT}/${TARBALL} unpack "./${TARBALL}" I realise at the moment there's only about two ebuilds that use the cdrom functions, but for it to make it into eutils, we must've had more in the past, and for all the vmware-*-tools ebuilds (where VM ship it as a "virutal CD" that gets mounted upon request) it'd be nice to have this. I'd tend to agree that the stuff that's already in eutils is probably best kept there.
OK, so the plan is basically move all unpack code from /usr/lib/portage/bin/ebuild.sh to ${PORTDIR}/bin/unpack-0.sh and change ebuild.sh to contain source ${PORTDIR}/bin/unpack-0.sh then add the features there. Probably more code could be moved and the file called ebuild-0.sh ( the -0 is to allow a -1 for incompatible changes ) So what is holding this change back now? :) What is it that I need to do to get this solved?
obviously no one from portage cares here .. and no one wants to say it
does it make you feel better if i say i dont care ?
allows me to not spend any time on this any more. Get it out of the list of the bugs I filed, too
It's a pity, I was rather looking forward to being able to unpack absolute paths, it's hit me a few times...
