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

Fix casks with depends_on that reference pre-Yosemite #58046

Closed
vitorgalvao opened this issue Jan 28, 2019 · 29 comments
Closed

Fix casks with depends_on that reference pre-Yosemite #58046

vitorgalvao opened this issue Jan 28, 2019 · 29 comments

Comments

@vitorgalvao
Copy link
Member

@vitorgalvao vitorgalvao commented Jan 28, 2019

If you get an error of the type Error: Cask 'hex-fiend-beta' definition is invalid: invalid 'depends_on macos' value: ":lion", where hex-fiend-beta can be any cask name, and :lion any macOS release name, run the following command:

/usr/bin/find "$(brew --prefix)/Caskroom/"*'/.metadata' -type f -name '*.rb' -print0 | /usr/bin/xargs -0 /usr/bin/perl -i -pe 's/depends_on macos: \[.*?\]//gsm;s/depends_on macos: .*//g'

This will remove all depends_on macos references of installed casks (where it doesn’t matter anymore anyway).

We should deal with these cases better in the future.

@glhrmv
Copy link

@glhrmv glhrmv commented Feb 2, 2019

I was trying to uninstall the keka cask and I couldn't because of this error message. Thank you.

@ran-dall
Copy link
Member

@ran-dall ran-dall commented Feb 2, 2019

@vitorgalvao I remember that we had a conversation with @core-code about trying 'us' trying to support as many releases of macOS as possible. I now see what you were saying about the high maintenance overhead...

Maybe we should have it a harder requirement of only supporting the last two releases of macOS. I know it doesn't fix the issue, but it would mitigate it a bit by not having as many tags. 🏷

We should consider that we're talking ~31% of users; which are on something different from the last two releases of macOS.

@vitorgalvao
Copy link
Member Author

@vitorgalvao vitorgalvao commented Feb 2, 2019

@Rand-all This specific lack of support for pre-Maverick is now enforced in the core, with the release of Homebrew 2.0.0 (today!).

@ran-dall
Copy link
Member

@ran-dall ran-dall commented Feb 2, 2019

@vitorgalvao Yea I saw about an hour after I wrote that...haha! 👍 So should we start to delete the support off casks?

@reitermarkus
Copy link
Member

@reitermarkus reitermarkus commented Feb 2, 2019

I think we can safely remove depends_on: '>= :mavericks'.

@ran-dall
Copy link
Member

@ran-dall ran-dall commented Feb 2, 2019

@reitermarkus 🧞‍♂️It shall be done, then...

@brianbrownton
Copy link
Contributor

@brianbrownton brianbrownton commented Feb 5, 2019

@brianbrownton
Copy link
Contributor

@brianbrownton brianbrownton commented Feb 6, 2019

@felker
Copy link
Contributor

@felker felker commented Feb 8, 2019

By the way, if you have edited your PATH environment variable so that GNU sed is the default, @vitorgalvao's command won't work as written:

sed: can't read /depends_on macos:/d: No such file or directory

Be sure to use BSD sed, e.g.:

/usr/bin/find "$(brew --prefix)/Caskroom/"*'/.metadata' -type f -name '*.rb' -print0 | /usr/bin/xargs -0 /usr/bin/sed -i '' '/depends_on macos:/d'

@vitorgalvao
Copy link
Member Author

@vitorgalvao vitorgalvao commented Feb 8, 2019

Thank you @felker. Added /usr/bin/ to the other tools as well, just in case.

@brianbrownton
Copy link
Contributor

@brianbrownton brianbrownton commented Feb 10, 2019

Is there something that can be done from the HBC side to prevent folks having to deal with this?

@vitorgalvao
Copy link
Member Author

@vitorgalvao vitorgalvao commented Feb 10, 2019

Is there something that can be done from the HBC side to prevent folks having to deal with this?

Old casks (i.e. the ones in .metadata) are the cause of issues like this. We can:

  1. Fallback to the current cask when the stored one gives an error.
  2. Instead of storing the cask at the moment of install, generate a bash file with the uninstall commands.

There’s an issue I’m not finding where we spitballed more ideas. It’s not #49716, though that one also has some of them.

@brianbrownton
Copy link
Contributor

@brianbrownton brianbrownton commented Feb 10, 2019

If I sub a PR to brew that would check if the metadata file exists and update it to work with the current release without causing issues, is that something that would be desired?

@vitorgalvao
Copy link
Member Author

@vitorgalvao vitorgalvao commented Feb 10, 2019

check if the metadata file exists and update it to work with the current release

The problem isn’t metadata files not existing; it’s that they exist but are old (i.e. use deprecated features). Replacing them with the current release outright would defeat the purpose — we want those old instructions, which is why we keep the files.

I see option 2 as more desirable, because that would decouple the uninstall (and zap) instructions from cask functionality, meaning they’ll be resilient to DSL changes.

Even so, before making a PR it would be desirable to open an issue to discuss the exact solution.

@brianbrownton
Copy link
Contributor

@brianbrownton brianbrownton commented Feb 11, 2019

My proposal is basically just to run the sed pipe you provided on the metadata file (for installed casks only, yea?) on brew update so that people don't have to run it manually. I was only interested in doing it if it was a quick fix, I don't really want to open an issue and get into a big thing about how to fix this... I guess I'm not THAT altruistic ;)

@vitorgalvao
Copy link
Member Author

@vitorgalvao vitorgalvao commented Feb 11, 2019

@brianmorton Ah, yes, my suggestion was about fixing it for every future case. I don’t think a fix for this particular one is necessary. The issue seems to be doing its job — people are finding it OK and not opening too many issues about it.

@mxr576
Copy link

@mxr576 mxr576 commented Feb 24, 2019

The suggested command breaks Onyx, because it defines dependencies in an array.

Error: Cask 'onyx' is unreadable: /usr/local/Caskroom/onyx/.metadata/3.5.6/20190115061551.579/Casks/onyx.rb:30: syntax error, unexpected ',', expecting keyword_end

@haykam821
Copy link
Contributor

@haykam821 haykam821 commented Feb 25, 2019

When I opened #57996, the old versions were referenced incorrectly (mountain_lion instead of :mountain_lion). As such, a simple find/replace for :mountain_lion or other old versions didn't work. Perhaps we should have a script that checks if a cask's version references are outside of symbolic names or version strings.

@vitorgalvao
Copy link
Member Author

@vitorgalvao vitorgalvao commented Feb 25, 2019

Perhaps we should have a script that checks if a cask's version references are outside of symbolic names or version strings.

No need for a script, that should be part of audit, as it was invalid code.

@zubrakadzo

This comment has been minimized.

@vitorgalvao
Copy link
Member Author

@vitorgalvao vitorgalvao commented Mar 2, 2019

@zubrakadzo Run the line in the top post.

@zubrakadzo

This comment has been minimized.

@metayan

This comment has been minimized.

@vitorgalvao
Copy link
Member Author

@vitorgalvao vitorgalvao commented Mar 6, 2019

Updated the top one-liner to cover multi-lines cases enclosed by []. If you find any other cases that fail, please let me know.

@vrillusions

This comment has been minimized.

@thom4parisot

This comment has been minimized.

@cypher004

This comment has been minimized.

@vitorgalvao
Copy link
Member Author

@vitorgalvao vitorgalvao commented Apr 3, 2019

@cypher004 The solution is in the top post. Please read before posting.

There haven’t been any meaningful comments in this issue for a while, so I’ll lock it.

@Homebrew Homebrew locked and limited conversation to collaborators Apr 3, 2019
@vitorgalvao vitorgalvao changed the title Fix casks with depends_on that reference pre-Mavericks Fix casks with depends_on that reference pre-Yosemite Jun 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests