Undo change adding --force-local option to invocation of tar

[mackler]

A commit on June 15 changed the invocation of tar always to use the --force-local option, which some common versions of tar lack and which will cause such versions of tar to fail to run. I understand the reason for the change is based on the behavior of the version of tar used by http://www.mingw.org/wiki/msys.

The option in question changes tar's interpretation of archive names that contain a colon. Versions of tar that support the --force-local option will generally interpret a colon as meaning that the archive name refers to a remote tape drive, and using that option disables that behavior. Meanwhile, versions that lack that option also lack support for remote archives. For reference, see:

• Gnu Tar Manual
• FreeBSD Tar Manual

The June 15 change was a consequence of someone having a problem caused by a colon in the name of an archive, which apparently is a situation caused by the nature of absolute paths in Windows. I lack knowledge of anything further regarding such problem, in particular the number of people affected.

What I do know is that this plugin, sbt-native-packager, is used by the popular Play Framework. The latest version of Play depends on version 1.0.1 of sbt-native-packager, and thus still invokes tar without the --force-local option. If and when a new version of Play is released that depends on a newer version of sbt-native-packager that invokes tar with the --force-local option, an untold number of projects that are currently deployable will become undeployable as a result of upgrading the Play version.

If I had to guess, I would expect that use of sbt-native-packager on systems with non-gnu versions of tar, such as FreeBSD, is more widespread than its use on Windows systems with MinGW. I admit I lack an objective measurement to support that guess. Whether or not that guess is consistent with reality, but more so if it is, the change of June 15 swaps a problem for some people with a problem for other people. While I agree a problem for anyone is undesirable, the principle of backwards-compatibility prefers the status quo, wherein those with a problem are aware of it already, over changing one problem for another, whereby an indeterminate number of working projects will break unexpectedly.

I also note that I could not find any warnings in the sbt-native-packager documentation alerting users that upgrading sbt-native-packager so as to apply the change introduced on June 15 will cause some previously working configurations to break.

For the foregoing reasons I conclude that while neither always nor never invoking tar with --force-local is optimal for everyone, the choice of always omitting that option is less bad than the alternative of always including it, and thus reverting this plugin's invocation of tar to its status quo before June 15 will place this project in a less-bad state than it currently is in. Merging this pull-request will effect that reversion.

---

For further reference see Issue 662

[muuki88]

Thanks for your detailed arguments. I agree that

an untold number of projects that are currently deployable will become undeployable as a result of upgrading the Play version.

is something we should definitely avoid.

If I had to guess, I would expect that use of sbt-native-packager on systems with non-gnu versions of tar, such as FreeBSD, is more widespread than its use on Windows systems with MinGW.

Unfortunately we have too guess as well. And our best guess would be to make it work on every system. Which brings me to my inital proposal on #662

Configurable tar options

We should introduce a new setting in Keys.scala

universalTarOptions = TaskKey[Seq[String]]("universal-tar-options", "description")

that holds different settings for tar-ing. The evaluated setting will be passed to the makeTarball function to customize the tar command. A good default for this setting would then be

universalTarOptions := Seq("-pcvf")

Users with windows and ; in their path name can customize this with

universalTarOptions += "--force-local"

@mackler Could you change your pull request to this suggestion? Reverting this change is not an option IMHO as we shut out other users again.

[mackler]

Could you change your pull request to this suggestion?

I'm happy to do whatever I am able. Are you asking me to implement the addition of the universalTarOptions setting? I could try but I expect the result would be that someone who knows what he's doing would spend more time fixing my attempt than it would have taken him to have done it properly from scratch.

For instance, I am ignorant of where the default setting would go. I guess it would be somewhere in UniversalPlugin.scala but beyond that I would probably guess wrong.

I wish I could be more useful. I am barely at the point of being able to use sbt competently. Contributing changes to a plugin is beyond my current competence. Still, if that's what it will take to get this fixed then I will do as much as I am able.

[muuki88]

Contributing changes to a plugin is beyond my current competence

That's totally fine ;) I'll add this and cc you on the pull request for testing.