[Questa mail non è una risposta a chi scrive queste gratuite scempiaggini, mi rivolgo a coloro che leggono sperando che non diffondano ulteriormente questa sciocchezza sui trampoli - sciocchezza nata da un colossale misunderstanding di una frase, in inglese, del manutentore del pacchetto.]
In data giovedì 22 marzo 2012 13:30:45, Felix ha scritto: > Ciao, > E' chiarito dallo stesso manutentore: si tratta di problemi > "ideologici", il manutentore non vuole favorire l'utilizzo di simili > "strumenti". Nessun motivo ideologico: il manutentore del pacchetto ha avuto altro da fare. In questa mail del 18 marzo spiega i motivi del ritardo e la sua futura tabella di marcia. saluti ##### Hi. Apologies for not having the time to follow up on everything I should. Studying leaves you with less free time than you'd think, and the accelerated plan I'm following just makes it worse, and when you also need a paid job and stuff in order to be able to afford it all, you inevitably get behind on things you really should be doing. The time I thought I'd have during Christmas was spent reading a 1000-page book. So, ever since last year, I've been feeling guilty about not being able to get around to work on the Wine package again. It's not the only thing I've been neglecting, either, nor is it really at the top of my list of backlogged things to work on whenever I do have some free time, so I'm starting to think that, instead of continuing to hope to get the time "soon", perhaps I should outline what my design requirements for the packaging is, and maybe someone else could help with the patches to fulfill them. Due to past experiences, I've become a bit unwilling to give privileged access to the project to people I don't have reason to trust, but your help might convince me. As my last changelog says when I uploaded in December, I do not insist on packaging every release between 1.2 and 1.4. However, at the time, it was my plan to package every release *until* 1.2 for quality-assurance reasons, because I wanted the packaging to fulfill my requirements, and to be tested, *before* I used that packaging for 1.3/1.4 or whatever. My objectives before packaging 1.2 included: 1) Coinstallability of wine and wine-unstable. The steps involved includes: - use separate directories for wine and wine-unstable (done) - make sure Wine's build system uses the correct directories (done) - add -unstable suffix to /usr/bin binaries (done) - use Debian's alternatives system to choose whether to use wine or wine-unstable (mostly done) - make sure Wine (and Winelib wrappers) always launches the correct version of itself for subprocesses (not done) - decide on a policy for winemenubuilder etc (not done) 2) Coinstallability and interoperability of 32-bit and 64-bit Wine. Combined with the above, this implies that 4 versions of Wine can be installed on the same system. - packages must build on multiarch; on multiarch, a 64-bit build cannot build 32-bit wine (mostly done, need to flip a switch in debian/rules and fix problems) - for backporting, the packages must also build on non-multiarch, in which case a dpkg-buildpackage should build both 64-bit and 32-bit (a backporter should only have to flip that switch in debian/rules back in order to get this, or better, perhaps debian/rules could autodetect somehow) - use separate directories for 32-bit and 64-bit wine (mostly done) - add 32 or 64 suffix to /usr/bin binaries (mostly done) - use Debian's alternatives system to choose whether to use 32-bit wine or 64-bit wine by default, should be same system as wine/wine-unstable above (mostly done) - Wine must work if either or both versions are installed, and the correct one should run if the user runs wine32 or wine64, including subprocesses. Also keep in mind that the user's WINEPREFIX may contain a fake a 32-bit or a fake 64-bit Windows installation, depending on whether the 32-bit or 64-bit Wine created it; you cannot run a 64-bit Wine instance on a 32-bit WINEPREFIX, so always defaulting to 64-bit is not an option. (not done) - Even if the 64-bit Wine is default, it would be nice if Wine automatically ran its 32-bit version if it was asked to run a 32-bit program, and in this case, emulate 64-bit Windows's WOW32 (32-bit Windows emulation). Needs to work with multiarch, and fail gracefully if wine32 is not installed. (not fully investigated) There might be more, I can't quite remember. Ove Kåven ##### -- Per REVOCARE l'iscrizione alla lista, inviare un email a [email protected] con oggetto "unsubscribe". Per problemi inviare un email in INGLESE a [email protected] To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
