Hi everyone, I just wanted to update you all on the state of the Wine packages for Debian; back in July, the difference between the "wine-development" and "wine" packages came up, not to mention which version WineHQ's download page should actually point to. Although it's fresher than the stable release of Wine, the default version of the wine-development package in Jessie is outdated by almost a year now. Over the past couple of months though, Jens Reyer worked with the Debian wine packaging team on backporting an up-to-date version of wine-development for Jessie. That Jessie-Backports package became available right around the beginning of September so now there's a curated way for users on Debian Stable to track the upstream development releases. IIUC, the Backports version tracks the package in Testing so it will still fall behind some while Testing is in a code-freeze, but it's a good compromise with Debian's goals, plus the policy for Backports is that they should only track Unstable for critical reasons. When closing out my bug report, Jens mentioned that upgrading the wine-development packages directly from the Jessie version to Jessie-Backports still may take some manual tweaking, though he's working on resolving that. He also recommended that instead of having the WineHQ download page link to... https://packages.debian.org/stable/wine-development we aim the link at the list of all living versions of the wine-development package: https://packages.debian.org/wine-development He also suggested that if it doesn't cause problems, we keep a link to the stable release package, just in case someone prefers it (or they're still stuck on oldstable): https://packages.debian.org/wine I can probably squeeze in some time in the next few days to submit those changes myself. - Kyle
On 09/10/2015 01:48 AM, Kyle Auble wrote:
Hi everyone,
I just wanted to update you all on the state of the Wine packages for Debian; back in July, the difference between the "wine-development" and "wine" packages came up, not to mention which version WineHQ's download page should actually point to. Although it's fresher than the stable release of Wine, the default version of the wine-development package in Jessie is outdated by almost a year now.
Over the past couple of months though, Jens Reyer worked with the Debian wine packaging team on backporting an up-to-date version of wine-development for Jessie. That Jessie-Backports package became available right around the beginning of September so now there's a curated way for users on Debian Stable to track the upstream development releases. IIUC, the Backports version tracks the package in Testing so it will still fall behind some while Testing is in a code-freeze, but it's a good compromise with Debian's goals, plus the policy for Backports is that they should only track Unstable for critical reasons.
When closing out my bug report, Jens mentioned that upgrading the wine-development packages directly from the Jessie version to Jessie-Backports still may take some manual tweaking, though he's working on resolving that. He also recommended that instead of having the WineHQ download page link to... https://packages.debian.org/stable/wine-development we aim the link at the list of all living versions of the wine-development package: https://packages.debian.org/wine-development He also suggested that if it doesn't cause problems, we keep a link to the stable release package, just in case someone prefers it (or they're still stuck on oldstable): https://packages.debian.org/wine I can probably squeeze in some time in the next few days to submit those changes myself.
Hi, I'm said person doing the backports and other stuff at Wine-Debian. So the current wine development version is now regularly updated in the backports suite for Debian stable, yay! Thanks for bringing this up at Debian directly, Kyle. Wine and Debian will win by being closer together and talking directly, here and there. (I'll try to answer more promptly *here* in the future, as well as I will help on the wiki here.) I don't worry too much about the backports being hit by the pre-release freeze. This is only the standard procedure, and I think we can convince Debian's backports admins to make an exception in about 14 months when the next freeze starts. Now, for all those wondering about the *usefulness of wine stable*: yes, please! I see the need and usefulness of wine-development for many people, and therefore I promised to maintain them in backports at least for Debian Jessie (i.e. probably the next 2 years). But this is only an additional service for users who have a reason to leave the stable path of their system. The occasional user is happy to know that Wine exists and that it works for an awesome lot of applications (and will do so for the next time, because neither the system or wine will change frequently). I'm sure they are the vast, but silent, majority. FYI, the imo *main differences of wine-development in Debian* (unfortunately they exist, but we're working on removing them if possible): - You need a suffix "-development" for the commands themselves, e.g. wine-development, winecfg-development, ... . I saw some confusion about this here at winehq, so for now: yes, these commands exist and work fine. And yes, hopefully soon we will make wine-development working also with unsuffixed command names. (https://bugs.debian.org/758291) - WoW64 is not supported, yet. Instead separate prefixes ~/.wine and ~/.wine64 are used automatically unless specified otherwise. (https://bugs.debian.org/762058). - wineserver is not in PATH but in an arch specific subdirectory in /usr/lib (works flawlessly for plain wine, but is a pita for 3rd party stuff like winetricks and PlayOnLinux). - Download of gecko and mono packages is disabled. - wine-development is currently built without capi, hal, gphoto, gstreamer, sane and v4l. Greets jre (Jens Reyer)
- wineserver is not in PATH but in an arch specific subdirectory in /usr/lib (works flawlessly for plain wine, but is a pita for 3rd party stuff like winetricks and PlayOnLinux).
Also a pita for people who advise typing things like 'wineserver -k'? Are they really supposed to know to look in this directory? Why is it in an arch-specific subdirectory when wineserver is designed to be architecture independent (same interface, and potentially the same server instance, used with 32-bit and 64-bit clients)?
- wineserver is not in PATH but in an arch specific subdirectory in /usr/lib (works flawlessly for plain wine, but is a pita for 3rd party stuff like winetricks and PlayOnLinux).
Also a pita for people who advise typing things like 'wineserver -k'? Are they really supposed to know to look in this directory?
Why is it in an arch-specific subdirectory when wineserver is designed to be architecture independent (same interface, and potentially the same server instance, used with 32-bit and 64-bit clients)?
Er, sorry, I missed the part where you were describing the current state and not necessarily advocating for it. Never mind. Although now this part seems a bit odd: On Fri, Sep 18, 2015 at 2:34 PM, Jens Reyer <jre.winesim(a)gmail.com> wrote:
- Download of gecko and mono packages is disabled.
Doesn't keeping it (so that the wine package downloads a binary blob not built by Debian) violate their principles?
Disclaimer: I talk about the state of Wine in Debian on a best effort basis. I am involved in packaging, but I am not the maintainer. My opinion is not authorative. On 09/18/2015 10:29 PM, Vincent Povirk wrote:
- wineserver is not in PATH but in an arch specific subdirectory in /usr/lib (works flawlessly for plain wine, but is a pita for 3rd party stuff like winetricks and PlayOnLinux).
Also a pita for people who advise typing things like 'wineserver -k'? Are they really supposed to know to look in this directory?
Why is it in an arch-specific subdirectory when wineserver is designed to be architecture independent (same interface, and potentially the same server instance, used with 32-bit and 64-bit clients)?
Er, sorry, I missed the part where you were describing the current state and not necessarily advocating for it. Never mind.
Np :) Is this true also without WoW64? I thought not (please tell me otherwise). So on a 64-bit system we need both the 32-bit and the 64-bit server installed. So currently I can't think of a better solution, because we don't have WoW64 yet.
On Fri, Sep 18, 2015 at 2:34 PM, Jens Reyer <jre.winesim(a)gmail.com> wrote:
- Download of gecko and mono packages is disabled.
Doesn't keeping it (so that the wine package downloads a binary blob not built by Debian) violate their principles?
Maybe a misunderstanding (I used packages confusingly): Indeed Debian disables the download of the mono and gecko *binary blobs*. Downloading them wouldn't fit Debian's policy and definition of free software. I doubt we will change that (this would probably mean moving wine from the "main" repository to official-inofficial "contrib"). Therefore changing that at its root is "not possible". Instead Debian provides gecko packages directly. Unfortunately they aren't updated regularly enough, so atm you can only use them for wine stable. That leaves you with downloading gecko and mono manually and placing them in the correct folder. ... which is broken for gecko currently (https://bugs.debian.org/783428). Imo our TODO is to fix the latter and communicate instructions better to the user. btw: for the same "political" reasons Debian disables the download of the Khronos XML API Registry for building wine. Instead khronos-api was packaged especially for this and is now a part of Debian. Greets jre
On 09/18/2015 01:34 PM, Jens Reyer wrote:
Thanks for bringing this up at Debian directly, Kyle. Wine and Debian will win by being closer together and talking directly, here and there. (I'll try to answer more promptly *here* in the future, as well as I will help on the wiki here.)
I've started working on a Debian-specific download page for WineHQ (modeled on the Ubuntu one); I should be able to submit a patch for review before the weekend's up. After that, I'll be taking a break from Debian issues for a while, but I'll still be subscribed to the mailing list.
Now, for all those wondering about the *usefulness of wine stable*: yes, please!
I'm not at Wineconf, but isn't Michael S. giving a talk about exactly this? I already mentioned my (not very weighty) opinion in another email, but I think we should be asking two distinct questions about wine's stable release: 1. Is there value in having a stable release? 2. Should it be decided on upstream and the same for everyone? My view is "definitely yes" for #1 but "probably not" for #2. Especially with git and the mature infrastructure of the distros these days, it makes more sense to me to let each distro follow their own timeline - resync their git tree with WineHQ's, pick a dev release to fix as stable, create a branch there, then apply their custom patches and occasional upstream bug-fixes on top. I get the impression that's the approach many of the other flagship FOSS projects have settled into.
I see the need and usefulness of wine-development for many people, and therefore I promised to maintain them in backports at least for Debian Jessie (i.e. probably the next 2 years). But this is only an additional service for users who have a reason to leave the stable path of their system. The occasional user is happy to know that Wine exists and that it works for an awesome lot of applications (and will do so for the next time, because neither the system or wine will change frequently). I'm sure they are the vast, but silent, majority.
I can see why WineHQ still recommends the dev release for most users at this point. I did have similar concerns to yours though, when I asked in my bug report if the "wine-development" package should be part of the normal Debian Stable repo. I wanted to ask if both people here at WineHQ and at Debian packaging could keep an eye out for relevant data over the next year or so. Particularly, I wonder... 1. Will many questions from Debian Stable users about "wine-development" being outdated pop up on the Wine forums or IRC? 2. Will the install ratio for Backports vs. Stable "wine-development" grow significantly as Jessie ages (if popcon can distinguish between the two)? 3. Ditto for "wine" vs. "wine-development". I'd interpret any of those things as a sign that the frozen version of "wine-development" on Stable might be redundant (and the 3rd that you're right about most Debian users being fine with the stable release). The Debian team could take that into account when deciding what to include in Stretch. - Kyle
On 09/19/2015 03:48 AM, Kyle Auble wrote:
On 09/18/2015 01:34 PM, Jens Reyer wrote:
Now, for all those wondering about the *usefulness of wine stable*: yes, please!
I'm not at Wineconf, but isn't Michael S. giving a talk about exactly this? I already mentioned my (not very weighty) opinion in another email, but I think we should be asking two distinct questions about wine's stable release: 1. Is there value in having a stable release? 2. Should it be decided on upstream and the same for everyone?
My view is "definitely yes" for #1 but "probably not" for #2. Especially with git and the mature infrastructure of the distros these days, it makes more sense to me to let each distro follow their own timeline - resync their git tree with WineHQ's, pick a dev release to fix as stable, create a branch there, then apply their custom patches and occasional upstream bug-fixes on top. I get the impression that's the approach many of the other flagship FOSS projects have settled into.
Yes of course for #1, but also for #2. There are 1046 commits between 1.5.31 and 1.6.2, from these 687 commits between 1.5.31 (2013-05-24) and 1.6 (2013-08-07). This is an awesome quality effort by winehq. Of course at some point this is void for a completely outdated stable release, but imo this is counted in years: Wine has so many use cases, and much is working even with a years old, but mostly regression free and thoroughly looked over version. I think single distributions can't do this, neither by developers (manpower and technical knowledge), nor by users required for this. Which distributions actually use development releases as base for their default Wine release? E.g. kernel releases are first taken care of by upstream. Only later the distributions take over maintainership. btw (just my 2 cent): I think dropping release goals would make more frequent Wine releases, and following this their support, much easier. Dropping a release goal doesn't mean you don't value the goal, it just states that it wasn't ready at the release date. There is no loss in releasing without some new feature. Debian does this by specifying the next freeze date directly after the release, this turned out to work much better then waiting for everything being ready.
I see the need and usefulness of wine-development for many people, and therefore I promised to maintain them in backports at least for Debian Jessie (i.e. probably the next 2 years). But this is only an additional service for users who have a reason to leave the stable path of their system. The occasional user is happy to know that Wine exists and that it works for an awesome lot of applications (and will do so for the next time, because neither the system or wine will change frequently). I'm sure they are the vast, but silent, majority.
I can see why WineHQ still recommends the dev release for most users at this point. I did have similar concerns to yours though, when I asked in my bug report if the "wine-development" package should be part of the normal Debian Stable repo. I wanted to ask if both people here at WineHQ and at Debian packaging could keep an eye out for relevant data over the next year or so.
Particularly, I wonder... 1. Will many questions from Debian Stable users about "wine-development" being outdated pop up on the Wine forums or IRC? 2. Will the install ratio for Backports vs. Stable "wine-development" grow significantly as Jessie ages (if popcon can distinguish between the two)? 3. Ditto for "wine" vs. "wine-development".
I'd interpret any of those things as a sign that the frozen version of "wine-development" on Stable might be redundant (and the 3rd that you're right about most Debian users being fine with the stable release). The Debian team could take that into account when deciding what to include in Stretch.
There is no version data in popcon. We can only compare wine and wine-development, and look both at "Installed" (including occasional users, which are also stable's target group, but also one-time users) and "Vote" (regular users). atm wine stable leads by a factor of about 20. But interpreting that number and its future changes is quite hard. Greets jre
On Fri, Sep 18, 2015 at 9:48 PM, Kyle Auble wrote:
Particularly, I wonder... 1. Will many questions from Debian Stable users about "wine-development" being outdated pop up on the Wine forums or IRC?
I doubt this as a practical problem. You can always tell them to reproduce it with a newer version, pointing them to the wiki page about Debian's backport packages.
2. Will the install ratio for Backports vs. Stable "wine-development" grow significantly as Jessie ages (if popcon can distinguish between the two)?
I don't think the popcon interface can query for backports vs. stable numbers.
3. Ditto for "wine" vs. "wine-development".
The data [0] shows users favoring the stable release by a factor of 20:1; granted this is only year one with a development package being available that is only 4 months in Debian stable, and more than 10 years with the stable package. That data also shows interest in the stable version stagnating, and interest in the development version growing. Anyway, somewhat unexpectedly different user have different needs. Some favor stability, and others favor bleeding edge. That is why there are longterm, stable, mainline, next, and various other linux kernel versions available to pick from. Why not support them all at least in some way? Upstream really needs to take the lead on making those decisions, otherwise distributions have no idea which to pick from, and end up with an arbitrary snapshot. Best wishes, Mike [0]https://qa.debian.org/popcon-graph.php?packages=wine%2Cwine-development&show...
On 09/19/2015 12:48 PM, Michael Gilbert wrote:
On Fri, Sep 18, 2015 at 9:48 PM, Kyle Auble wrote:
Particularly, I wonder... 1. Will many questions from Debian Stable users about "wine-development" being outdated pop up on the Wine forums or IRC? I doubt this as a practical problem. You can always tell them to reproduce it with a newer version, pointing them to the wiki page about Debian's backport packages.
You're right, it's definitely not a major problem; I was more interested in keeping tabs on how often it happens as a data-point. I'm just wondering if the confusion earlier this summer was a one-time thing or if it will keep recurring even as word gets out about the wine-development package. On 09/19/2015 12:48 PM, Michael Gilbert wrote:
I don't think the popcon interface can query for backports vs. stable numbers.
On 09/18/2015 10:32 PM, Jens Reyer wrote:
There is no version data in popcon. We can only compare wine and wine-development, and look both at "Installed" (including occasional users, which are also stable's target group, but also one-time users) and "Vote" (regular users).
I thought that might be the case when I tried looking for the data. It surprised me a little though because I figure including the package version in the popcon reports wouldn't be too hard. If there's not something else preventing it (like security), that might be something I look into down the road. On 09/19/2015 12:48 PM, Michael Gilbert wrote:
The data [0] shows users favoring the stable release by a factor of 20:1; granted this is only year one with a development package being available that is only 4 months in Debian stable, and more than 10 years with the stable package.
That data also shows interest in the stable version stagnating, and interest in the development version growing.
Yeah, "wine-development" is still too young to claim anything from the data, but I noticed the trend too. What I found interesting is if you actually break apart the data for "wine" into the four different fields, there's still growth in the number of recent users (though "old" users are increasing faster); most of the stagnation in total installations comes from a massive drop in the number of "no-files" [1]. On 09/19/2015 12:48 PM, Michael Gilbert wrote:
Anyway, somewhat unexpectedly different user have different needs. Some favor stability, and others favor bleeding edge. That is why there are longterm, stable, mainline, next, and various other linux kernel versions available to pick from. Why not support them all at least in some way? Upstream really needs to take the lead on making those decisions, otherwise distributions have no idea which to pick from, and end up with an arbitrary snapshot.
On 09/18/2015 10:32 PM, Jens Reyer wrote:
Yes of course for #1, but also for #2. There are 1046 commits between 1.5.31 and 1.6.2, from these 687 commits between 1.5.31 (2013-05-24) and 1.6 (2013-08-07). This is an awesome quality effort by winehq. Of course at some point this is void for a completely outdated stable release, but imo this is counted in years: Wine has so many use cases, and much is working even with a years old, but mostly regression free and thoroughly looked over version.
I think single distributions can't do this, neither by developers (manpower and technical knowledge), nor by users required for this. Which distributions actually use development releases as base for their default Wine release? E.g. kernel releases are first taken care of by upstream. Only later the distributions take over maintainership.
btw (just my 2 cent): I think dropping release goals would make more frequent Wine releases, and following this their support, much easier. Dropping a release goal doesn't mean you don't value the goal, it just states that it wasn't ready at the release date. There is no loss in releasing without some new feature. Debian does this by specifying the next freeze date directly after the release, this turned out to work much better then waiting for everything being ready.
I think we actually agree for the most part and I've been using the phrase "development release" in a confused way (in the sense of a regular release from the tip of mainline, not in the sense that there hasn't been any code-freeze or focus on QA... I probably have Wine's release schedule in mind). You're both absolutely right that the release-candidate procedures should be handled upstream, plus the more regularly they happen, the better. It's interesting you both mentioned the Linux kernel too because that's the example I had in mind (along with Firefox and Chrome). They don't have alternating stable and development versions anymore, but rather use branches off of mainline more liberally. I didn't think of it at first, but you're also right that it makes a lot of sense for all those branches to be hosted upstream. At the same time, aren't the actual branches managed independently? That was the picture in my head when I said I thought downstream should have more say in deciding which release is stable. After thinking about what you both said, I can see that probably isn't the right approach, but I still feel like even if the branches happen under one roof, they should fall to independent teams. Once everyone gets back from Wineconf though, it will be interesting to see if a consensus is forming on the stable vs. development question. - Kyle [1] https://qa.debian.org/popcon-graph.php?packages=wine&show_vote=on&show_old=o...
participants (4)
-
Jens Reyer -
Kyle Auble -
Michael Gilbert -
Vincent Povirk