Today I created an RPM for a fairly oddly-installed software package (I do this frequently). If you're not familiar with RPM, one its features is the use of "pristine sources"?the software author's distributed files are used as-is and modified in a repeatable way by the RPM build process.
Anyway, the package in question is ENVI 4.3.1. The ENVI 4.3 distribution conforms to their traditional semi-bizarre installation scheme, but the 4.3.1 patch is more interesting. I wanted to install the 4.3.1 patch as a part of the RPM build process, and found that the patch package was a collection of archives within archives.
It occurred to me to unpack these nested archives with one long pipeline, instead of unpacking to a temporary location, unpacking again, etc. The traditional rpmbuild process seems to favor using gzip -dc and tar -xf - instead of tar -xzf - which, for one of the patch archives, would have looked like this:
gzip -dc envi431linux.tar.gz | tar -xf - envi_platform.tar -O | tar -xf - envi431.linux.tar.gz -O | gzip -dc | tar -xf -
Which makes me chuckle. I first uncompress the distributed file (envi431linux.tar.gz), unpack the named file (envi_platform.tar) from that archive, unpack the desired file (envi431.linux.tar.gz) within that archive, and then uncompress and unpack that last archive. This applies the patch archive without using a temporary directory.
Since I'm already using the probably-not-standard -O option with tar, I could just go the rest of the way and compact it to:
tar -xzf envi431linux.tar.gz envi_platform.tar -O | tar -xf - envi431.linux.tar.gz -O | tar -xzf -
"Pristine sources" and lame installers equals fun scripts!
