#122 Issue closed: Unwanted dependency on tar ?

Labels: cleanup, discuss / RFC

dagwieers opened issue at 2012-06-26 10:17:

At the moment we use tar in a few cases to copy files around:

  • usr/share/rear/rescue/default/01_merge_skeletons.sh
  • usr/share/rear/build/GNU/Linux/10_copy_as_is.sh

This means that tar is a hard dependency for a functional Relax-and-Recover, while this is not necessarily needed for most use-cases. It is also unclear to me why we use tar in this way, rather than using cp. I would like to get rid of the need for tar for all but specific tape use-cases, unless there is a good reason why we do this.

@schlomo @gdha Consider this issue a "call for information" ;-)

schlomo commented at 2012-06-26 16:03:

Tar is always available (unlike pax :-)) so I don't see this as a bad

IMHO tar | tar is a better cp for many applications because

  • it supports exclude patterns
  • it is more of a streaming copy as we have two tar processes that stream
  • (old) unix wisdon recommends tar over cp

What exactly disturbs you about tar? What is the business value of getting
rid of it? Is it really a top prio now?

dagwieers commented at 2012-06-26 16:53:

It is not so much a "disturbance" than it is looking to reduce the number of dependencies. I certainly was not going to propose pax instead as an alternative.

And no, it is not a top priority or even a priority. Issues are a way to keep track of things we might want to do (much like those feature requests that may never happen). I opened it against v1.15 and not against v1.14 so it definitely is not going to be tackled the coming month...

I am not convinced about using tar where a simple cp would do fine.

PS If you think I am singling out tar for some reason, I am not. We have been adding tar "features" and for me it is important to see where we might want to plug in a more generic feature mechanism for tools. Currently "features" are spread out all over the place, and in the case of tar "features" I am now testing features after those basic uses of tar. That's why I bring this up now after closing the problem created by the #67 issue, unfortunately it was not tracked by an issue.

gdha commented at 2013-03-15 12:34:

@dagwieers is there still a reason to keep this open? IMHO it will never change due to time constraints...

dagwieers commented at 2013-03-15 12:46:

If the aim is to decrease the number of issues, I guess you can close it. On the other hand, the number of issues does not seem that important to me if they're categorized well. Feel free to do whatever you prefer :-)

[Export of Github issue for rear/rear.]