-
Notifications
You must be signed in to change notification settings - Fork 130
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
Why not restore support into Homebrew upstream? #1056
Comments
I don't know the history of the project and have only been contributing for a few months so take this with a pinch of salt but there's a question regarding the technical aspect of doing such a thing of what you asked about, that we can maybe answer if we pretend we're going to set off now on implementing it. |
A few of the things I've written for Tigerbrew have actually made it upstream; when it's practical, I do try to commit them in both places. However, as a practical matter, there's a few things that don't necessarily fit with Homebrew's strategy for dealing with things. Keeping a separate project gives me the flexibility to do some things separately, my own way. Homebrew's update schedule also doesn't play nicely with older OSs. On Tigerbrew, keeping things updated to their latest versions at all times would mean a lot of software wouldn't work; we tend to need more testing here, and update things when we know they work. It makes more sense to have a separate package directory for that. The other thing I'll note is that Homebrew's been moving away from from-source builds and a "hacker-friendly" approach and towards a binary-friendly support. Tigerbrew, being targeted at hobbyists with older hardware, is better-suited to taking a different approach. Having a separate repository makes it easier for me to make decisions specifically for Tigerbrew's users. |
@mistydemeo Thank you, fair enough. Pre-built binaries would require own infrastructure to pre-build something, of course, which upstream would not bother to have. So Ruby version is not a constraint at the moment, or you bootstrap a modern Ruby? P. S. A side question: when building from source, does the existing implementation allow what you can do in [Macports] portfiles, i.e. choose specific compiler etc. |
Yep, exactly. Even if it was possible to get enough PowerMacs/Xserves together to build everything at the scale Homebrew would need, builds would fail much more frequently than on other platforms and they'd take much longer to run. A compromise where (most of) the support application code from Tigerbrew also makes it into Homebrew, but Tigerbrew has a totally separate package repository, is much easier to maintain and lets us update Tigerbrew on the schedule that works for it.
I bootstrap a modern Ruby. For awhile I did actually run Tigerbrew on the system Ruby 1.8.2/1.8.6, but eventually that became an issue. Instead, Tigerbrew downloads a prebuilt Ruby on first run.
Yes! You can pass |
@mistydemeo Out of curiosity, which version do you use on 10.4? I have fixed Ruby 3.1 and later in upstream (and Macports) for 10.5 and 10.6 on PowerPC, but I am not sure Tiger could handle them. Though to be honest I perhaps never tried. |
Right now it's 2.3.3; I'm planning to upgrade sometime, but just haven't gotten around to it. Likewise, |
As I recall, up to v. 2.5 it should build with no patching, then 2.6 through 3.0 are broken, 3.1 and later should work. |
Could someone help me with a short summary, what was the primary reason for having this as a separate fork rather than just maintaining some [limited] support for older OS in Homebrew itself? (To be clear, I have no association with the latter whatsoever, I am just interested to understand the status of the project.)
Was it decided it is easier or technically superior or just Homebrew upstream was determined to break support for older OS no matter what?
Or rather something trivially historical, happened that way?
The text was updated successfully, but these errors were encountered: