https://bugs.winehq.org/show_bug.cgi?id=40363
Bug ID: 40363 Summary: Wine Stabilization - Gentoo Slow to Adopt With Valid Reason Product: Wine-staging Version: 1.8.1 Hardware: x86-64 URL: https://bugs.gentoo.org/show_bug.cgi?id=578202 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: ecyoung@grandecom.net CC: erich.e.hoover@wine-staging.com, michael@fds-team.de, sebastian@fds-team.de Distribution: Gentoo
I opened the bug that I'm asking you to comment on. I opened this bug because Gentoo's Stable version is still at 1.6.2. I use an old RPG, Istaria which is blocky in 1.9.5, and Eve Online, which is unplayable in my case using 1.6.2. In order to properly regression test where my issues are coming from, I thought I would start at finding out why Gentoo's stable version lagged behind WineHQ's stable version. Our package maintainer is doing the best he can, as our distribution is source based, and he is perfectly within his right not to use a custom patchset (See Comment 3).
Comment 7 in my bug states:
Let's keep this open with the info from NP-Hardass so that anybody else who seeks for 1.8.1 knows.
I'm closing #578272 as I see no point of having it open. NP-Hardass stated he wants to bump and stabilize 1.8.x, so it's on upstream now.
Thanks for your interest Carter, maybe try to convince upstream to get it going ;)
----------------------------------------
Bug 578272 was implemented as a tracker, but the commenter is correct in assuming that the issue lies upstream. I present Snippets from Comment 3:
I'd prefer that our stable wine 1.8 use the official gstreamer 1.0 patchset, but upstream never released that under the 1.8 branch. Once again though, I'd rather not be hosting a custom patchset for stable. There is currently a request to the upstream wine stable maintainer to include this in 1.8.2.
1.8.1 was never bumped because Wine Staging never released a patchset for 1.8.1 and I'd rather not have a stable candidate in package.use.stable.mask and not have staging support. I'd also rather not have to host a custom staging patch just for 1.8.1. I've cc'd the Staging devs in case they'd like to weigh in on making an official release for 1.8.1.
----------------------------------------
https://bugs.winehq.org/show_bug.cgi?id=40363
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |np.hardass@gmail.com Summary|Wine Stabilization - Gentoo |Wine Staging should provide |Slow to Adopt With Valid |updated patchsets for |Reason |stable releases
--- Comment #1 from Sebastian Lackner sebastian@fds-team.de --- I assume your primary concern is that Wine Staging doesn't provide updated patchsets for stable releases like 1.8.1, is that right? If not, feel free to correct me.
I've already talked to NP-Hardass privately during the last days, and although I can understand that its much easier to have a Staging patchset for all versions of Wine, it doesn't really make much sense from a logical point of view. Wine Staging represents the Staging branch of Wine, and mainly concentrates on experimental features. From time to time such features also break applications which would otherwise run fine, so I would strongly suggest to avoid the staging USE flag when you mainly interested in stability. Those two choices are basically contradicting each other. If there is really a USE-case where it this choice makes sense, I would like to know it.
I've also added NP-Hardass to the discussion.
https://bugs.winehq.org/show_bug.cgi?id=40363
--- Comment #2 from Carter Young ecyoung@grandecom.net --- I totally understand the concept of staging.
Gentoo's documentation at: https://wiki.gentoo.org/wiki/Wine
states: staging Apply Wine-Staging patches for advanced feature support that haven't made it into upstream Wine yet For versions before wine-1.8, this patchset is unofficial.
My Available Wine Versions: [I] app-emulation/wine Available versions: 1.6.2^t (~)1.6.2-r1^t (~)1.7.3-r1^t (~)1.7.4-r1^t (~)1.7.8-r1^t (~)1.7.9-r1^t (~)1.7.10-r1^t (~)1.7.11-r1^t (~)1.7.12-r1^t (~)1.7.13-r1^t (~)1.7.14-r1^t (~)1.7.15-r1^t (~)1.7.16-r1^t (~)1.7.17-r1^t (~)1.7.18-r1^t (~)1.7.19-r2^t (~)1.7.20-r1^t (~)1.7.21-r1^t (~)1.7.22-r1^t (~)1.7.28-r1^t (~)1.7.29-r1^t (~)1.7.33-r1^t (~)1.7.34^t (~)1.7.35^t (~)1.7.36^t (~)1.7.37^t (~)1.7.38-r1^t (~)1.7.39-r1^t (~)1.7.40-r1^t (~)1.7.41^t (~)1.7.42^t (~)1.7.43^t (~)1.7.44^t (~)1.7.45^t (~)1.7.46^t (~)1.7.47^t (~)1.7.50^t (~)1.7.51^t (~)1.7.52^t (~)1.7.53^t (~)1.7.54-r1^t (~)1.7.55^t (~)1.8^t (~)1.9.4^t (~)1.9.5^t **9999^t
---------------------------------------------------------
The USE Case here is that I don't have what WineHQ considers to be a stable version in my tree because of a USE Flag argument?? I can't report bugs against 1.6.2 here anymore, because my bug would be closed after being told to upgrade, and I'm surely not submitting a bug here against the bleeding edge testing version, when I have 3 minor version changes in between.
Why tell our maintainer that he has access to the staging patchset, and then not supply one? The issue here is that once a USE Flag is created in a certain package it's expected to be backwards compatible. You can't enable the option in 1.8, and then disable the option in 1.8.1. For that matter you can't enable it in 1.8 and expect it to work in 1.6.2, hence the wording above. If the stable versions aren't meant to include the staging patchset, then you and our package maintainer need to decide how to remove the staging USE Flag from all versions. This is complicated by the fact that we can use Stable and Unstable versions. The intent here was that the unstable versions contain the staging USE Flag. Using your logic, we would need to mask the staging Flag for each version marked stable, using package.use.stable.mask?
The intent of a mask in Gentoo implies that a package isn't completely stable, i.e our maintainer is having to be a hardass to quell the small riot we'd have among our userbase that understands cascaded masking.
I CANNOT BELIEVE THIS has been going on over a year or more. I'm ashamed to say that I missed out on a 1.7.x stable branch because of this same argument
https://bugs.winehq.org/show_bug.cgi?id=40363
--- Comment #3 from Sebastian Lackner sebastian@fds-team.de --- (In reply to Carter Young from comment #2)
The USE Case here is that I don't have what WineHQ considers to be a stable version in my tree because of a USE Flag argument?? I can't report bugs against 1.6.2 here anymore, because my bug would be closed after being told to upgrade, and I'm surely not submitting a bug here against the bleeding edge testing version, when I have 3 minor version changes in between.
When filing a bug, you will always be asked to test with one of the latest development versions - no matter if you use 1.6.2 or 1.8.1. The current development version (1.9.6) is about three months ahead of stable and already contains plenty of improvements in various areas. Nevertheless, the lack of packages for 1.8.1 on Gentoo is something we cannot fix here at WineHQ. NP-Hardass will take care of that, just be patient a bit.
Why tell our maintainer that he has access to the staging patchset, and then not supply one? The issue here is that once a USE Flag is created in a certain package it's expected to be backwards compatible. You can't enable the option in 1.8, and then disable the option in 1.8.1. For that matter you can't enable it in 1.8 and expect it to work in 1.6.2, hence the wording above. If the stable versions aren't meant to include the staging patchset, then you and our package maintainer need to decide how to remove the staging USE Flag from all versions. This is complicated by the fact that we can use Stable and Unstable versions. The intent here was that the unstable versions contain the staging USE Flag. Using your logic, we would need to mask the staging Flag for each version marked stable, using package.use.stable.mask?
We never announced that we would provide Staging patchsets for stable versions because, as pointed out above, it is a contradiction. If people want experimental features, then they can use Wine Staging - if they prefer stability over new features, then they can use the stable version of Wine without Staging.
Please note that 1.8.0 is basically both "stable" and "development" at the same time. Afterwards, the development branch continued with 1.9.0 (for which we provide Staging patchsets) and the stable branch with 1.8.1 (which only gets minor bugfixes to increase stability).
I am not sure what the best way is to fix the Gentoo packages, but since we always had a good contact to NP-Hardass in the past, I am pretty sure a solution suitable for everyone can be found quickly.
The intent of a mask in Gentoo implies that a package isn't completely stable, i.e our maintainer is having to be a hardass to quell the small riot we'd have among our userbase that understands cascaded masking.
I CANNOT BELIEVE THIS has been going on over a year or more. I'm ashamed to say that I missed out on a 1.7.x stable branch because of this same argument
1.7.x/1.9.x are development branches of Wine, not stable branches. Besides that, I have no idea what you are complaining about. I am not aware of any other version not available on Gentoo because of the lack of a Staging patchset.
https://bugs.winehq.org/show_bug.cgi?id=40363
--- Comment #4 from Carter Young ecyoung@grandecom.net --- (In reply to Sebastian Lackner from comment #3)
1.7.x/1.9.x are development branches of Wine, not stable branches. Besides that, I have no idea what you are complaining about. I am not aware of any other version not available on Gentoo because of the lack of a Staging patchset.
I apologize ob that point, as I had not checked the WineHQ stable notification for a LONG TIME.
We never announced that we would provide Staging patchsets for stable versions because, as pointed out above, it is a contradiction. If people want experimental features, then they can use Wine Staging - if they prefer stability over new features, then they can use the stable version of Wine without Staging.
Please note that 1.8.0 is basically both "stable" and "development" at the same time. Afterwards, the development branch continued with 1.9.0 (for which we provide Staging patchsets) and the stable branch with 1.8.1 (which only gets minor bugfixes to increase stability).
I would like to install a more recent stable version, without the staging USE Flag. The issue is that from 1.8 on, at least in Gentoo, the staging USE Flag will be an option, meaning for every version we mark stable, a staging patchset WILL BE required, for example, 1.8.3 is marked stable, and the staging USE Flag is enabled.
Let me ask it this way: Say you decide that Wine Stable will become 1.9.5. At the moment 1.9.5 is chosen, is the staging patchset removed? If it is removed, our package in Gentoo breaks, as the staging flag existed before the decision.
https://bugs.winehq.org/show_bug.cgi?id=40363
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
--- Comment #5 from Sebastian Lackner sebastian@fds-team.de --- (In reply to Carter Young from comment #4)
I would like to install a more recent stable version, without the staging USE Flag. The issue is that from 1.8 on, at least in Gentoo, the staging USE Flag will be an option, meaning for every version we mark stable, a staging patchset WILL BE required, for example, 1.8.3 is marked stable, and the staging USE Flag is enabled.
I hope you agree that the whole problem is very Gentoo-specific. If wine-staging would be provided as a separate package (like on basically all other distributions), it would be trivial to provide it only for versions which are officially supported by the Wine Staging team. ;)
I've talked to NP-Hardass, and based on the fact that porting the 1.8 patchset to 1.8.1 is basically trivial, I've decided to push such a version to the Wine Staging repository. Users have to be aware though that such a version is neither good from a stability perspective (staging patches stay experimental), and also not from a staging perspective (because its outdated), so use at your own risk. ;)
https://bugs.winehq.org/show_bug.cgi?id=40363
--- Comment #6 from Austin English austinenglish@gmail.com --- (In reply to Carter Young from comment #4)
Let me ask it this way: Say you decide that Wine Stable will become 1.9.5. At the moment 1.9.5 is chosen, is the staging patchset removed? If it is removed, our package in Gentoo breaks, as the staging flag existed before the decision.
1.odd releases are always development, 1.even is stable, fyi. 1.9.5 won't suddenly become stable. At some point the next stable will announced, with a code freeze, which versions become 1.10-rcx (or it may be 2.0-rcx, can't recall the decision at Wineconf..).
In other words, development releases don't arbitrarily become stable.
https://bugs.winehq.org/show_bug.cgi?id=40363
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #7 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Closing Fixed Staging 3.14
-
wine-bugs＠winehq.org