5

I'm working on something in a Makefile that will look something like this:

tarball:
        mkdir -p tmp/tarball/etc/service
        mkdir -p tmp/tarball/usr/local
        mkdir -p tmp/tarball/opt/myproject
        cd sensordatad; make
        cd sensortunneld; make device_name
        cp -r sensorservices tmp/tarball/etc/service
        # Make a tarball here, something like:
        #   chroot tmp/tarball; tar -czvf myproject.tar.gz .

The idea is that I'll be able to move into the ./tmp/tarball directory, and create a tarball which when unpacked on a system will unpack itself to /etc/service, /usr/local and to /opt/myproject.

The classical approach seems to be to use tar -czvf -C tmp/tarball . but this leads to a tar listing of entries that start with ./.

I'm inspired by the package from the Go language, which indicates that it should be installed with:

tar -C /usr/local -xzf go1.0.3.linux-amd64.tar.gz

Which would be ideal for my use-case, I'd like to be able to do:

tar -C / -xzf myproject.tar.gx

Which would in turn extract the files originally in ~/some-working-directory/tmp/tarball/_____ to /_____, meaning that I could simply fake the installation structure.

Of course this might better be achieved with something like fpm, which I haven't ruled out, but I'm not keen on heavy weight solutions, and I assumed that I'd be able to do this without resorting to Ruby.

I've stumbled upon fakechroot, which seems promising, but not surprisingly, tar doesn't exist in the chroot, and when I started going down that rabbit hole I just assumed I was doing something wrong and should ask for assistance.

4
  • 1
    As a sysadmin, the idea of manually unpacking a tarball into the root of my system makes me cry. What you want to do is generally handled by an install script; if you ever plan to upgrade or uninstall your program, or plan to release it, please consider packaging it properly with a .deb and .rpm. /opt doesn't exist on my system! Tarballs are great for source distribution, or where the entire application can be unpacked to a single folder anywhere on the system and run from there. May 14, 2013 at 20:45
  • Acknowledged Darth Android, but we're provisioning RaspberryPis for delivery out to customers, and as we already build the entire rootfs as a tarball (using debootstrap) before imaging it onto the SD cards, this solution doesn't seem too evil. May 14, 2013 at 21:06
  • Fair enough! Embedded systems change the game :) May 14, 2013 at 21:09
  • 1
    have you considered creating a disk image and dd'ing that to the raspberry? it should be a good deal faster than tar (and will pick up stuff that tar can't like partitions etc)
    – skarface
    Apr 5, 2016 at 23:43

2 Answers 2

3

From the GNU tar manual:

When tar extracts archive members from an archive, it strips any leading slashes (`/') from the member name. This causes absolute member names in the archive to be treated as relative file names. This allows you to have such members extracted wherever you want, instead of being restricted to extracting the member in the exact directory named in the archive. For example, if the archive member has the name `/etc/passwd', tar will extract it as if the name were really `etc/passwd'.

Thus my tar creation looks like this:

tar -czvf myproject.tar.gz -C tmp/tarball ./
./
./etc/
./etc/service/
./etc/service/sensorservices/
./usr/
./usr/local/
./opt/
./opt/myproject/

When this is installed with:

sudo tar --directory / -xzf ./myproject.tar.gz
sudo tar -C / -xzf ./myproject.tar.gz

Then everything works as expected, for better or for worse.

0

Why are you doing it so complicated?

cd tmp/tarball; tar -czvf ../../myproject.tar.gz .

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .