It would be nice if ebuilds could pass options to the tar command invoked by the unpack function declared in ebuild.sh. There is already a variable called tar_opts, but it is local to that function, set to "" initially, and otherwise never assigned to. So I can see no practical use in it right now. It would be easy to make this variable global, and probably better still to have a global variable TAR_OPTS, i.e. with an uppercase name. One application would be to drop CVS dirs (like dohtml does during install) or .svn dirs (like the latesn mplayer tarballs have, see bug 172198) during extraction already, saving disk space and extraction time for information that is known to be unneeded. It might even be worth considering to add those two exclude options by default, so ebuild writers have to take no special action to save these resources. In the rare case where those files might actually be needed, the ebuild could still set TAR_OPTS="" in src_unpack to avoid the default.
Created attachment 114527 [details, diff] Patch ebuild.sh to initialize tar_opts This patch initializes tar_opts to TAR_OPTS if set (even if set to ""), and otherwise provides two default arguments, one excluding ".svn" and one "CVS".
do you have any other examples ? using it to filter .svn and CVS sounds pretty frivolous to me, plus it now allows ebuild writers to introduce non-portable tar options
(In reply to comment #2) > do you have any other examples ? I don't know any other ebuild where I'm sure this would apply, no. But there are a lot of ebuilds out there for plugins that for some reason or other require the sources of the main program. E.g. enigmail unpacks a whole thunderbird tree, though I would guess it only uses a few header files or some such. On such occasions a lot of memory could be saved by only unpacking the necessary files. > using it to filter .svn and CVS sounds pretty frivolous to me, Well, at least .svn keeps a duplicate of every file, which results in twice the size you'd otherwise have, although it should compress to almost nothing inside the tarball. Just for one single ebuild it's not worth much of a fuss, but if other packagers should decide to do something similar, I'd be very much for dropping that ballast as soon as possible. > plus it now allows ebuild writers to introduce non-portable tar options Good point. So maybe it should not be an arbitrary environment variable, but rather a set of flags to unpack itself, resulting in either portable options or in some emulation. I believe include/exclude is still the most important application. Right now it is the only one I can think of.
while integrating the flag into unpack would address the portability option, we'd then have to worry about translating that to each archiver ;( yeah, .svn can contain a lot, but generally tarball releases shouldnt contain the .svn dirs as you need to download that extra overhead as well, so maybe you should request upstream that the dirs be excluded when rolling snapshot tarballs :) if we get a more pressing need for this we can revisit this, but until that point time ...
