Skip to content

Commit

Permalink
openssl: delete (#46876)
Browse files Browse the repository at this point in the history
  • Loading branch information
@fxcoudert
fxcoudert authored Nov 21, 2019
1 parent 30fd2b6 commit 0349a7c
Show file tree
Hide file tree
Showing 2 changed files with 0 additions and 101 deletions.
1 change: 0 additions & 1 deletion Aliases/openssl@1.0
View file

This file was deleted.

100 changes: 0 additions & 100 deletions Formula/openssl.rb
View file

This file was deleted.

6 comments on commit 0349a7c

@les-okta
Copy link
Contributor

@les-okta les-okta commented on 0349a7c Nov 21, 2019 •
edited
Loading

Choose a reason for hiding this comment

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

This deletion is now of course breaking tons of machines for us again ;)

Is there a reason openssl.rb can't be 1.1 and have openssl@1.1 be an alias?

I'm happy to add a PR for that if you think this is appropriate. Thoughts?

@Bo98
Copy link
Member

@Bo98 Bo98 commented on 0349a7c Nov 21, 2019 •
edited
Loading

Choose a reason for hiding this comment

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

We're considering this, yes. It may involve revision bumping hundreds of formulae which depend on it though.

What's the exact breakage you are having though? OpenSSL 1.0 and 1.1 aren't exactly binary compatible so if something depended on 1.0 it probably won't work with 1.1 libraries.

In terms of Homebrew, no other formulae uses OpenSSL 1.0 any more.

@les-okta
Copy link
Contributor

Choose a reason for hiding this comment

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

We have a machine bootstrap script that ensures this package, e.g.

brew list openssl >/dev/null 2>&1 || brew install openssl

because we have other scripts/tools that explicitly reference the openssl binary/command.

We're updating our bootstrap script now to reference openssl@1.1, but it would have been nicer if openssl always meant "the latest stable openssl version as determined by the Homebrew team" and haveopenssl@1.1 as an alias back to the (newly modified) openssl.rb file.

While this was a bit startling for us, it's also a quick fix for us, so I'm not terribly concerned. I just thought the openssl as always the latest stable version would be nice for users like us that explicitly reference it.

In this particular case, given the pervasiveness of the OpenSSL library, I can understand why that might not have been done for legacy and stability reasons. Maybe this is something that can be done in the future?

In any event, thank you for the hard work you guys continue to do for the project!

@Bo98
Copy link
Member

@Bo98 Bo98 commented on 0349a7c Nov 21, 2019 •
edited
Loading

Choose a reason for hiding this comment

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

openssl always meant "the latest stable openssl version as determined by the Homebrew team"

You're absolutely right in terms of how our version policy normally works. What would have normally been done was that openssl was exactly that and openssl@1.0 was what was removed today.

Unfortunately, for reasons that would've been decided on far before I was around (likely complications of having hundreds of formulae depend on it), that wasn't the case for openssl. It ultimately lead to in the end us actively discouraging using openssl over openssl@1.1, while many people would've been unaware of that. Indeed the confusion meant that we had a couple of new formula submitted using openssl as a dependency when openssl@1.1 was preferred.

I suppose the upside is that now you explicitly depend on 1.1. So if 3.0 came around tomorrow and broke everything again, your workflow won't fall apart from upgrading a openssl that may point to the latest version.

We'll figure out how to deal with the unversioned openssl.

@Bo98
Copy link
Member

@Bo98 Bo98 commented on 0349a7c Nov 21, 2019

Choose a reason for hiding this comment

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

We've got #47034 open now to discuss further.

@fxcoudert
Copy link
Member Author

Choose a reason for hiding this comment

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

Apologies for the breakage. I don't think there was a clean way to do it, we were always going to have to break it for some users. The decision not to make openssl always be the latest version, which was linked to the scale of changes to be made, ended up biting us in the end.

In this particular case, given the pervasiveness of the OpenSSL library, I can understand why that might not have been done for legacy and stability reasons. Maybe this is something that can be done in the future?

We're definitely going to do that at some point, the problem is trying to do it without breaking things for users who currently have OpenSSL 1.0 installed as openssl…

Please sign in to comment.