Der lange Weg von Wine 1.4 nach Debian Wheezy

Es hat länger gedauert als viele gedacht hätten. Doch nun ist es soweit und Debian hat ein aktuelles und stabiles Wine in Version 1.4 in seinen Repos. Da ich Wine in der Vergangenheit für einige bekannte Spiele wie World of Warcraft oder Starcraft II benutzt habe, hat mich das Schicksal dieses Pakets nicht kalt gelassen und mir später auch einige interessante Einsichten in die Entwicklung von Debian GNU/Linux gebracht.
Es stimmt, nicht jeder hält Wine, eine Zwischenschicht für Windows entwickelte Programme und dem Linuxkernel, für einen Segen. Ich denke jedoch, dass Wine denjenigen hilft, die irgendwo noch dieses eine, scheinbar unersetzbare, Windowsprogramm haben, dass sie vom kompletten Umstieg auf Linux abhält. Ich habe privat mit Windows nichts mehr am Hut, doch mir hat es in der Vergangenheit beim Wechseln auch geholfen, zugegeben bei einer sehr optionalen Sache wie Computerspielen.

Nun machte mich seit zwei Jahren stutzig, warum Debian mit einer vollkommen veralteten Wine-Version ausgeliefert wurde. Im Sommer letzten Jahres erfuhr ich dann, dass Wine einem sogenannten Code-Audit unterzogen wurde und das gesamte Paket so umgebaut werden musste, dass es sich mit den in Debian verfügbaren freien Werkzeugen auch bauen ließ.
Danach passierte lange Zeit nichts. Der Paketverwalter hatte keine Zeit mehr. Einige engagierte Helfer arbeiteten trotzdem weiter, hatten aber nur eingeschränkte Rechte. Sie wurden vom ursprünglichen Paketverwalter nicht als Teammitglieder aufgenommen und hatten deswegen keine Möglichkeit eine neuere Version hochzuladen.

Erst als einer der Helfer, Michael Gilbert, schließlich zum Debianentwickler "befördert" wurde, durfte er sogenannte NMUs von Wine einstellen. Diese Non-Maintainer-Uploads sind in der Regel nur dafür gedacht um ein gravierendes Problem mit einem Paket zu lösen, wenn der ursprüngliche Paketverwalter keine Zeit dafür hat. Jeder Debianentwickler hat das Recht dazu. Die Pakete werden je nach Dringlichkeit in eine Warteschlange gepackt, so dass Zeit bleibt das Paket zu begutachten oder auch wieder zu entfernen, wenn es den Ansprüchen nicht genügen sollte.
Obwohl der Paketverwalter selbst nicht aktiv sein konnte, forderte er jedoch, dass jede einzelne Wine-Version in den letzten zwei Jahren nach und nach hochgeladen werden sollte. Spätestens hier begannen einige dann den Kopf zu schütteln.
Joey Hess brachte es dann auf den Punkt. Der Bug demonstriere Schwächen in prozeduralen und administrativen Bereichen. Anstatt zu versuchen ein perfektes Paket zu bauen, wäre es für die Mehrheit der Benutzer besser gewesen, wenn man einfach ein aktuelles Wine-Paket verfügbar gemacht hätte. Notfalls hätte man sich auch der Ubuntu-Version bedienen können, die nachweislich einwandfrei funktioniere.
Was mich später beeindruckt hat, war das Verhalten von Michael Gilbert, der wiederholt geschrieben hat, dass es ihm besser gefällt auf Zusammenarbeit zu setzen als die Konfrontation mit dem Paketverwalter zu suchen. Optionen wie Wine für sich zu beanspruchen ("Hijacking") schloss er z.B. ausdrücklich aus. Steve Langasek ging soweit zu sagen, dass Hijacking schlicht "asozial" sei und es weitere Prozeduren wie z.B. "Orphaning" oder das Technische Komitee gebe, womit dem Paket ein neuer Paketverwalter zugewiesen werden könne.

Am Ende wurden alle Helfer schließlich zu offiziellen Teammitgliedern des Wine-Pakets gemacht und die Arbeit konnte normal fortgesetzt werden. Der ganze Vorgang hat exemplarisch gezeigt, welche dynamischen Prozesse in einem Projekt wie Debian ablaufen, in dem jeder einzelne Entwickler eine sehr starke Stellung, aber auch viel Verantwortung hat.

Für alle Benutzer gibt es als Ergebnis nun zu vermelden, dass es sowohl möglich sein wird Wine 1.4 (stable) als auch die Entwicklerversion (im Moment 1.5) in Zukunft parallel zu installieren und Dank Multiarch sollte es später ebenfalls möglich sein, sogar 4 verschiedene Wine-Versionen parallel einzurichten. Happy End.