wine: Add wine-staging patchset as a (non-default) build option #27791
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Please fix the commit to follow the commit style: |
aeadio
changed the title
Chocimier
reviewed
Jan 9, 2021
aeadio
force-pushed
the
wine-staging
branch
2 times, most recently
from
250e839
to
785b66c
Compare
|
I don't like having `vopt_if` in distfiles and checksum. It is somewhat
clunky and I doubt that `xgensum` would work properly with that.
Another option would be to put an if block after the variable
declaration and append to the variables if necessary.
What workflow do you have in mind for wine and the staging build
option? In the current form, updating the wine package without also
updating the staging tarball would lead to a build option until someone
also updates staging. If the staging tarballs are released in a timely
manner after the wine release, perhaps putting the staging tarball
directly in distfiles would also be an option. The builder would then
extract both tarballs but only apply the staging patches when the build
option is set. I at least wouldn't mind waiting a day after a release
to update the wine package.
|
I was split on this and I agree. I opted to just include it in distfiles directly. The download isn't too large. While I was there, I also hoisted out the
It consistently tracks, and has only missed the 1 day window once in the past year. I think it's fine to pause it the extra day when needed. It's frequently released same-day. Does CI test non-default build options? |
No |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Because staging is not release quality, this is introduced as a non-default build option. Because users expect a certain level of breakage and imperfection in Wine in general, I think it's still fine to introduce as an option, despite Void's policy against non-release software. Wine-staging is frequently required to make some applications/games work.
Open question of what to do if wine-staging lags a upstream wine release by a bit -- block package updates? But at least for the last several versions, wine-staging has tracked wine closely, lagging in their releases by no more than 1 day.
Builds on x86_64 and i686. Tested on x86_64 with wine+wine-32bit multi.
closes #27612