Re: In debian, Wine ancora fermo alla 1.0
[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
#####
Reply to: