Overview
Request 512103 revoked
- Add _service for wine-staging and wine-d3d9-patches.
- Add _multibuild for staging, nine, and staging-nine packages.
Given this is reverting back to 2.12 it should not be accepted, but represents
a concept for review. If anything the staging and nine bits should have a new
variable that can trail behind the main wine version to ensure that wine
updates are not delayed even if that patches are broken and multibuild packages
stop working. Those can be updated when their upstreams update.
Additionally, I used the new obs_scm service for both the staging and nine
upstreams as the the current wine-staging.spec SOURCE100 using v2.12.tar.xz is
a rather suboptimal name especially when another source is added. Due to the
additional OBS builtime deps this makes the package unresolveable in a few
repos that is undesirable. I can go ahead and switch back to tar_scm and in
order to eleviate that.
These packages are not intended to be installed at the same time as the
Conflicts: otherproviders(wine)
should make clear, but this should make it clean to provide the three
additional variants that are rather commonly desired.
Please review the approach and I will make a followup request based on the
feedback.
- Created by boombatower
- In state revoked
-
Package maintainer:
msmeissn
Request History
boombatower created request
- Add _service for wine-staging and wine-d3d9-patches.
- Add _multibuild for staging, nine, and staging-nine packages.
Given this is reverting back to 2.12 it should not be accepted, but represents
a concept for review. If anything the staging and nine bits should have a new
variable that can trail behind the main wine version to ensure that wine
updates are not delayed even if that patches are broken and multibuild packages
stop working. Those can be updated when their upstreams update.
Additionally, I used the new obs_scm service for both the staging and nine
upstreams as the the current wine-staging.spec SOURCE100 using v2.12.tar.xz is
a rather suboptimal name especially when another source is added. Due to the
additional OBS builtime deps this makes the package unresolveable in a few
repos that is undesirable. I can go ahead and switch back to tar_scm and in
order to eleviate that.
These packages are not intended to be installed at the same time as the
Conflicts: otherproviders(wine)
should make clear, but this should make it clean to provide the three
additional variants that are rather commonly desired.
Please review the approach and I will make a followup request based on the
feedback.
msmeissn added msmeissn as a reviewer
marcus to handle
msmeissn accepted review
lets actually try this. staging delays might be provblematic, but well
msmeissn approved review
lets actually try this. staging delays might be provblematic, but well
kwk declined request
bad link: conflict in file _service
boombatower revoked request
The source project 'home:boombatower:branches:Emulators' has been removed
I created separate versions for nine and staging upstream patch target, but as expected staging patches do not apply. I would imagine this will happen fairly often so it may make sense to leave them all using %realver and simply disabling when new version of wine is published if they do not apply and re-enabling once new versions provided. Disabling can be done easily with something like:
in either staging or nine sections that define sources.
A second update could be provided when the upstreams update there patches. That way folks using base wine get updates quickly, while those who want to use the variants can still get them from Tumbleweed proper.
Given the current state, I would submit this with staging excluded while nine still builds, but I am testing with 2.12 since all patches apply.
I also switched to
tar_scmstyle service as I imagine that will be preferred. Additionally, I added provides and conflicts to all subpackages and baselibs.conf.Should also merge any other staging related build dependency changes for additional features.
done
I have to think about this.
This pretty much complicated the spec file.
I have wine-staging as seperate RPM in Emulators:Wine , and a direct3d9 fork could also live there.
I also have wine-snapshot for daily snapshots there.
Understandable. One thing I noticed in the wine-staging spec is there are seemingly unrelated changes in the spec likely due to the way it is maintained. Having the conditionals makes it simple to keep the differences all in the one place.
In general I do not see much added complexity. Basically just conditional parts that represent 4 different builds. The staging build already being present in a separate package and as noted being complicated by maintaining two totally separate specs which seems to be out of sync.
The workflow around when to update the other builds since they will likely trail behind wine releases by a few days simply needs to be decided and then followed.
The reason I am suggesting including them in the main package is that both staging and nine are maintained as patches and thus should start from the same base. Additionally, both staging and nine will never be merged into the primary upstream wine sources as intended, but are commonly needed to even utilize certain applications or provide usable performance. As such I imagine users would like to find them easily available.
A fair number of people have indicated they are actively using the wine-staging-nine builds. Not sure if you forgot about this, but it would be nice to have a decision.
@msmeissn: review reminder
@kwk: I mean come on....it's 4 month old request....of course it is going to have a conflict. Lets review the idea and I can easily supersede, but I need to know if wroth the bother.
I actually merged it manually 2 days ago.
I still not sure I like it as-is.
Staging is usually 1 week behind regular Wine, which delays the submission to Factory by 1 week.
I added the same code now in Emulators:Wine/wine, which is for the curious users of older distros.
Thanks! As for the submission deadline my thought was go ahead and submit new wine versions before staging and nine and make another submission once they are updated. That's basically how I had been maintaining my branch.
The staging and nine builds will break and therefore not update until the second submission. Alternatively, you can wait for everything as you suggested.