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

Versioned bottles? #60

Closed
carlobaldassi opened this issue Aug 13, 2014 · 10 comments
Closed

Versioned bottles? #60

carlobaldassi opened this issue Aug 13, 2014 · 10 comments
Labels

Comments

@carlobaldassi
Copy link

(Sorry if this is a trivial question, but I know nothing about Homebrew.)
I wanted to update GLPK.jl to use the latest version of the underlying library (from 4.52 to 4.54). The problem is that since libglpk does not guarantee backwards API/ABI compatibility, I require a specific version of the library in the Julia package.
However, the current rule for Homebrew in GLPK.jl is

provides(Homebrew.HB, "glpk", glpkdep, os = :Darwin)

Is it possible to have different versions of libglpk bottled, such that different releases of GLPK.jl keep working?

@staticfloat
Copy link
Member

Homebrew isn't really designed for multiple simultaneous versions. The best they do is making specific formulae for the versions, e.g. llvm33 to install llvm-3.3.

Right now only 4.52 is supported, and once Homebrew supports 4.54, they will likely drop support for 4.52 completely, and move over to 4.54. That being said, I can "freeze" the version of glpk if you need it, or create a glpk454 formula, or whatever you need. So if you just let me know what you need, we can work together to make it happen.

@carlobaldassi
Copy link
Author

Thanks! I think that having glpk-4.52 and glpk-4.54 formulas (etc.) is the only way multiple versions of GLPK.jl can be made to work.

@staticfloat
Copy link
Member

And multiple versions of glpk are necessary? Okay. I'll archive the current glpk formula as glpk-4.52 and see if I can't make a glpk-4.54 sometime soon.

@carlobaldassi
Copy link
Author

Thanks a lot! Also, if it's something I can do on my own (from Linux) I'd be happy to do it / maintain it.

@staticfloat
Copy link
Member

Can you go ahead and get ready to update all your packages that currently require glpk to instead require glpk452?

@carlobaldassi
Copy link
Author

Wouldn't that leave all previous versions is an unusable state?

@staticfloat
Copy link
Member

Anybody that already has glpk installed will continue to have it installed, and I'm keeping the glpk name around for a while longer, but if we're going to version one name, we should version all the names.

@carlobaldassi
Copy link
Author

Yes, leaving the glpk name around was what I had in mind. If we remove it, we might as well "retire" all versions of GLPK.jl which use it from METADATA.

I have updated the rule to use the versioned name in a branch.

@carlobaldassi
Copy link
Author

If we remove it, we might as well "retire" all versions of GLPK.jl which use it from METADATA.

Actually, thinking about it a little more, people who want to downgrade for some reason, or use a particular snapshot, could still resort to compiling from source, so that's not the case.
Moving forward, versioned formulas are still the only sane option to interact with Pkg though.

@staticfloat
Copy link
Member

I'm now retiring glpk. We still have glpk452 and glpk454 around, and it looks like glpk452 is still used by default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants