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

Why not restore support into Homebrew upstream? #1056

Open
barracuda156 opened this issue Jan 10, 2024 · 7 comments
Open

Why not restore support into Homebrew upstream? #1056

barracuda156 opened this issue Jan 10, 2024 · 7 comments

Comments

@barracuda156
Copy link

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?

@sevan
Copy link
Contributor

sevan commented Jan 13, 2024

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.
Do you see any technical hurdles in taking the upstream repo & adding back on legacy support going back to 10.4?

@mistydemeo
Copy link
Owner

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.

@barracuda156
Copy link
Author

@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.

@mistydemeo
Copy link
Owner

Pre-built binaries would require own infrastructure to pre-build something, of course, which upstream would not bother to have.

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.

So Ruby version is not a constraint at the moment, or you bootstrap a modern Ruby?

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.

when building from source, does the existing implementation allow what you can do in [Macports] portfiles, i.e. choose specific compiler etc.

Yes! You can pass --cc=WHATEVER. --cc=gcc-4.0 and --cc=gcc-4.2 let you pick the two versions provided by Apple, but you can also use Tigerbrew-provided GCCs.

@barracuda156
Copy link
Author

I bootstrap a modern Ruby

@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.

@mistydemeo
Copy link
Owner

Right now it's 2.3.3; I'm planning to upgrade sometime, but just haven't gotten around to it. Likewise, brew install ruby gives you 2.4.1 right now, but I'm planning to upgrade that to the latest.

@barracuda156
Copy link
Author

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.

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

No branches or pull requests

3 participants