Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use BSD tar's libarchive LZMA support if available #1279

Merged
merged 1 commit into from
Oct 15, 2016
Merged

Use BSD tar's libarchive LZMA support if available #1279

merged 1 commit into from
Oct 15, 2016

Conversation

MikeMcQuaid
Copy link
Member

@MikeMcQuaid MikeMcQuaid commented Oct 12, 2016

  • Have you followed the guidelines in our Contributing document?
  • Have you checked to ensure there aren't other open Pull Requests for the same change?
  • Have you added an explanation of what your changes do and why you'd like us to include them?
  • Have you written new tests for your changes? Here's an example.
  • Have you successfully run brew tests with your changes locally?

Avoid using an unnecessary xz dependency when it's not needed.

This may well require some refactoring and I need to confirm that these macOS versions are correct. Thanks to @zmwangx for pointing out that this was possible; I had no idea.

@MikeMcQuaid MikeMcQuaid added the in progress Maintainers are working on this label Oct 12, 2016
tar_flags << "z"
elsif cached_location.compression_type == :bzip2
elsif type == :bzip2
tar_flags << "j"
end
Copy link
Contributor

@zmwangx zmwangx Oct 12, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do the "older versions of tar" that "require an explicit format flag" happen to be tar on 10.6 or lower? In any case, even if it's unnecessary, IMO it would be better to add a clause for :xz:

elsif type == :xz
  tar_flags << "J"
end

which is arguably safer (no one needs to ask the older versions question I raised above), and at least feels more complete.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They could be, I'll double-check. Couldn't find the J in the manpage.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I don't see it in the manpage either, but it is in the --help string:

$ tar --help | grep '\-J'
  -z, -j, -J, --lzma  Compress archive with gzip/bzip2/xz/lzma

if type == :xz && MacOS.version < :lion
pipe_to_tar(xzpath)
else
safe_system "tar", tar_flags, cached_location
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about /usr/bin/tar? (xar path is hard-coded too.)

tar in pipe_to_tar (below, outside the current set of diffs) should be hard-coded too.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should definitely be /usr/bin/tar. We had a bug or two a while back when there were plain tar invocations.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is to make Linuxbrew's life a bit easier. We haven't seen any bugs with this for a long time. Once we have environment sanitisation we can hopefully start to filter a lot more PATHs out.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Care to list a Linux distro without a full blown /usr/bin/tar (other than embedded distros, e.g. busybox based ones liks OpenWrt)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're proposing making a change to additional code so the onus is not on me to research why I shouldn't change the existing code. It's not a bug we're seeing and I don't think speculative fixing like that is a sensible approach as it may break things for forks like Linuxbrew and it's not gaining us anything today. Again, happy to have a longer-term PATH-filtering solution that addresses all these cases and avoids us having to hard-code anything.

Avoid using an unnecessary `xz` dependency when it's not needed.
@MikeMcQuaid
Copy link
Member Author

This may well require some refactoring and I need to confirm that these macOS versions are correct.

Refactored so this works properly on non-macOS and confirmed that Lion was indeed the first version to support this. This adds additional weight to using xz bottles.

@MikeMcQuaid MikeMcQuaid merged commit 527a62b into Homebrew:master Oct 15, 2016
@MikeMcQuaid MikeMcQuaid deleted the use-tar-xz branch October 15, 2016 12:37
@MikeMcQuaid MikeMcQuaid removed the in progress Maintainers are working on this label Oct 15, 2016
@ilovezfs
Copy link
Contributor

Um

==> Verifying wget-1.18.tar.xz checksum
tar xJf /Users/joe/Library/Caches/Homebrew/wget-1.18.tar.xz
tar: Error opening archive: Child process exited with status 254Child process exited with status 254
Error: Failure while executing: tar xJf /Users/joe/Library/Caches/Homebrew/wget-1.18.tar.xz
/usr/local/Homebrew/Library/Homebrew/utils.rb:276:in `safe_system'
/usr/local/Homebrew/Library/Homebrew/download_strategy.rb:79:in `safe_system'
/usr/local/Homebrew/Library/Homebrew/download_strategy.rb:247:in `block in stage'
/usr/local/Homebrew/Library/Homebrew/utils.rb:254:in `with_system_path'
/usr/local/Homebrew/Library/Homebrew/download_strategy.rb:243:in `stage'
/usr/local/Homebrew/Library/Homebrew/resource.rb:95:in `block in unpack'
/usr/local/Homebrew/Library/Homebrew/extend/fileutils.rb:14:in `block in mktemp'
/usr/local/Homebrew/Library/Homebrew/extend/fileutils.rb:74:in `block in run'
/usr/local/Homebrew/Library/Homebrew/extend/fileutils.rb:74:in `chdir'
/usr/local/Homebrew/Library/Homebrew/extend/fileutils.rb:74:in `run'
/usr/local/Homebrew/Library/Homebrew/extend/fileutils.rb:13:in `mktemp'
/usr/local/Homebrew/Library/Homebrew/resource.rb:94:in `unpack'
/usr/local/Homebrew/Library/Homebrew/resource.rb:86:in `stage'
/usr/local/Homebrew/Library/Homebrew/formula.rb:1799:in `stage'
/usr/local/Homebrew/Library/Homebrew/formula.rb:1075:in `brew'
/usr/local/Homebrew/Library/Homebrew/build.rb:112:in `install'
/usr/local/Homebrew/Library/Homebrew/build.rb:187:in `<main>'

@ilovezfs
Copy link
Contributor

💣 #1299.

@Homebrew Homebrew locked and limited conversation to collaborators May 3, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants