-
Notifications
You must be signed in to change notification settings - Fork 38
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
should we rearrange qt5 packages for newer upstream releases? #1132
Comments
man I wish we could just use qt5 and a meta package that would install the highest available, that's what meta packages are for, the perl/pythong mess makes me nuts. |
So each qt5{7,15}-FOO pkg would Or meta = bundle? |
Meta is normally a bundle and it would be sooo much cleaner for reps but the bundle version couldn’t be a dep which would be a mess, multi dists with multi package versions is just a mess |
Unfortunately, there are 60+ qt5(.7) packages/splitoffs (and Qt6 count will be higher). Bundling by source package would require at least 25 bundles and then what's the point of SplitOffs if a Qt using package would just Depends on the bundle? I guess I don't understand how bundle packages would help with the different versioning. I've only dealt with bundle packages as convenience grouping to install a suite instead of individual apps. |
plus it wouldn't help as I mentioned, we couldn't version the bundles as each dish gets a different version, it's just a huge mess and a HUGE PITA |
We're stuck at Qt5.7 because Qt5.9 would start being dist restricted (10.11+) and Qt5.15 is 10.13+. Therefore, to have newer releases, we would need to either:
Pro of (1):
Drawbacks of (1):
Pro of (2):
Drawback of (2):
In either case, there's little point in having qt59 and qt512. We probably just want v5.7 and v5.15 with whatever naming convention at this point.
This will probably carry over to Qt6, where current latest v6.7.0 (no point in starting from 6.0) is only for Xcode14 or newer (macOS 12.5+)
Probably leaning towards No2 (new qt515 family) since it won't cause breakage.
I have a branch from a while back that does Option 2. @dhomeier has a PR #675 that does Option 1 but does not have the necessary dist restricting.
The text was updated successfully, but these errors were encountered: