Ubuntu Wiki

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

• Launchpad Entry: wine-gutsy-roadmap

• Packages affected: wine

Summary

We feel that the handling of wine in the past ubuntu releases has been sub-optimal. In order to improve the situation, we propose different approaches to encourage better maintenance of wine in ubuntu.

Rationale

During the development of past ubuntu releases, it has become clear the release process of wine is incompatible with the way ubuntu is developed. Wine is not really released at all, but is snapshotted about every two weeks. Old snapshots are not supported by upstream. Instead, users are advised to try out the newest version if problems arise.

After the UVF (Upstream Version Freeze), developers have been requested an UVF exception for every wine release. In each release, a lot of bugs have been fixed, but many other things get broken. It is not determinable by the UVF team if the new version was better or worse than the old one.

We need to determine how we want to deal with wine for ubuntu 7.10

Use Cases

• Joe needs to run a closed-source application. It requires the latest Wine release to work properly.
• Fred's application works. He doesn't want to update Wine because new versions sometimes have regressions.
• A new wine snapshot becomes available. John wants to try the new version.
• Bob notices that the new version of wine doesn't work with his new application. He wants to downgrade his existing wine installation to some earlier snapshot.
• Alice experiences crashes with her commercial windows application. She is guided how to create a useful bug report which makes it clear if the problem was in wine or in the windows application

Scope

This specification focuses on our release policy for the Gutsy Gibbon release (ff?).

Alice's problem requires changes in Apport and Upstream procedures and is thus out of scope.

Design

We strongly encourage that a wine team should be formed which triages and forwards bugs in Malone to upstream. Most of the bugs in malone are actually upstream bugs. We need to know which of those we can fix in ubuntu, and which of those need fixing upstream.

We have different options how to proceed:

1. We grant a general UVF exception to wine, so we always have the latest wine in the ubuntu archives. This handles use case 1.

2. We enforce the UVF policy WRT the wine package.

3. We remove wine from the archive, but provide a set of PPAs with several versions of wine available, which satisfies use case 2. In order to support use case 1, we need to extend the update-manager tool which checks if an PPA with a newer wine version is available, and offers to replace the entry in /etc/apt/sources.list with the PPA providing the up-to-date one.

4. Use case 3 requires forming an ubuntu-wine team, which discusses how to provide useful bugreports to the wine and apport developers.

5. We may want to upload new versions of Wine to -backports.

6. ... and then again, we might not want to do that because of possible (in fact, likely) regressions.

Implementation

Option 3 is more intrusive to Ubuntu's package management than we're willing to commit to at this time.

The consensus of the BoF is that, given the general state of maintainance of Wine in Ubuntu (or lack thereof), the best way to proceed is to always package the latest version, with a general UVF exception before release and regular -backport release afterwards.

If a Wine team forms which is able to do more focused maintainance, the MOTU Council will review this conclusion.

Remarks about Debugging Wine applications (Outstanding issues)

Note: This part is useful imformation about how to improve bugreports in wine, as noted in the 'scope' part, is a bit out of this spec.

shermann: Apport is totally useless in this case, please read for that: http://www.winehq.org/?issue=330 (debugging paragraph): Debugging

Stephan Hermann wrote in asking about how Ubuntu could provide better debugging reports:

As Scott Ritchie knows, I'm at the moment the reponsible person for Wine on Ubuntu. I hope that you all know, Ubuntu has a new system for filing crash reports and stacktraces. (named apport aka automatic crash reports, some documentation is found at https://wiki.ubuntu.com/Apport)

Those reports are working quite well for all apps in Ubuntu, but not as expected for Wine, especially when windows apps are involved.

We discussed yesterday about this problem, and now we want your help, to make things better.

What we need from you: what you need from us (Ubuntu) to get better backtraces when wine crashes (especially wine-preloader)

Stephan provided i an example of the debugging info currently generated. Marcus Meissner thought that information was pretty useless. He suggested setting Wine up to automatically generate a backtrace from winedbg:

With:

• [Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug] 1119019818 "Auto"="1" "Debugger"="winedbg --auto %ld %ld"

in the registry Wine will call winedbg automatically on a crash and get a Win32 aware backtrace.

It would already help to use wine-pthread instead of wine-preloader for generating the backtrace. (Just replace it as traced binary.)

Vitaliy Margolen suggested some other info to include as well:

In general the most useful pieces of information are ... complete terminal output, $PWD and the command used to start an application. Also the exact Wine version $(wine --version), and where did it came from (self-compiled or binary). All of them are absent from the report.

Discussion

Couldn't this be implemented by a more liberal repo of itself, with a more official consent? Following the rest of the guidlines drafted, it might just be easier not bending the current rules. I basically visualize this as an implementation problem more than anything, as was said win regressions though quickly fixed occur often, given having to wait a minimum of 2 weeks for it to be fixed... we most definitely would need to provide a way (a GUI of some sort?) to revert, which would also mean having many versions in the repositories.

shermann: right now, there is no stable release of wine...and from what I can see, wine will never be stable.

ScottRitchie: This isn't quite true. Wine fully plans on making a stable 1.0 release sometime within the next year - that would be the obvious version to include in Gutsy or Gutsy+1.

siretart: this proposal needs infrastructure we don't have. PPAs could be used for this, but they aren't there yet.

Discussion about the design regarding backports:

shermann: We do backports of wine already, when requested John is doing the backports.