unarchive requirements?

[Adam Morris]

Greetings,

According to the documentation unarchive requires tar/unzip to work...

However it appears from my first attempt at using it that it requires GNU tar to work.  Reading through the code it looks like it tries to determine what the archive format is and then supplies appropriate GNU tar options to the tar command in order to carry out its tasks.  

I haven't tested yet, but I suspect that I could provide it with an uncompressed tar file and have it work on AIX, but it certainly doesn't work with a compressed one.  

Does anyone have any thoughts on this?  I'm not sure how you could improve the module though...

Adam

[Brian Coca]

Since I'm already taking a look for issues with BSD directory detection, I might take a stab at making sure it is 'POSIX tar' compliant, sadly I have a lot of experience with that.

--
Brian Coca
Stultorum infinitus est numerus
0110000101110010011001010110111000100111011101000010000001111001011011110111010100100000011100110110110101100001011100100111010000100001

Pedo mellon a minno

[Brian Coca]

So it seems the big issue is having the compression support in tar (as GNU tar has), for other implementations we would need to always call the decompression program (gzip, etc).

[Leibo]

Just encountered this on a HP-UX server...

ansible -i inventory/test_hosts rx2600-hpux11iv3-x64 -u root -m shell -a "which tar"

rx2600-hpux11iv3-x64 | success | rc=0 >>
/usr/bin/tar

I suppose it would be nice to test the detected tar command flags, if we detect a 'z' option, use it, if not - do this in 2 steps - uncomress and unarchive

# ansible -i inventory/test_hosts rx2600-hpux11iv3-x64 -u root -m shell -a "tar z"
xavi-rx2600-hpux11iv3-x64 | FAILED | rc=1 >>
tar: z: unknown option

And failover to a 2 step solution.

[Michael DeHaan]

We're unlikely to want to run the extra steps to do the test all the time, and it would complicate the module considerably, I'd accept  a PR to add a hint to the unarchive module though.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/f6f28733-af68-412b-9ca4-1e9085eac1dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Leibo]

Thanks,

if we can have a new parameter to explicitly tell the module to use 2 steps, like, gunzip and then tar xf it would cover this non GNU tar situations.

[Michael DeHaan]

gnu=no (default yes) maybe?

On Tue, Jun 17, 2014 at 2:21 PM, Leibo <assaf...@gmail.com> wrote:

Thanks,

if we can have a new parameter to explicitly tell the module to use 2 steps, like, gunzip and then tar xf it would cover this non GNU tar situations.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/c1fded22-f5ba-4bbe-88c2-241bf86fc0d7%40googlegroups.com.

[Leibo]

Hi,

gnu=no/yes is great. 

BTW, if we have other commands inside modules relying on GNU perhaps it will be good to have also a system level parameter that will affect all such modules.

[Michael DeHaan]

We don't have any facility for module defaults like that at this time, so that may have to be considered later.

I'd consider it now if we didn't have so many other things to consider first :)

But yes, in this case, let's make gnu=yes/no so.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/de02173d-89ed-4a63-a449-72c5529cbad4%40googlegroups.com.