[pkg-wine-party] Proposed package cleanups
bengen at debian.org
Sat Jan 12 16:31:40 UTC 2013
* Michael Gilbert:
> I would prefer to not waste any more time on 1.4.
I don't see improving the 1.4 packages (and providing wheezy backports
of those, of course) at the same time as we improve the 1.5 packages as
a waste of time. Rather as a service to users.
> I'm not concerned about 32/64 at this point. Just wine vs.
I am concerned about both.
>> About co-installability of different Wine versions: I am not convinced
>> that alternatives for the wrapper scripts are useful here. What is
>> "notepad-unstable" supposed to mean? Let's get rid of those.
> So we would have different binaries in wine-bin vs. wine-bin-unstable?
> I would prefer to retain symmetry.
We already have differernt binaries in wine-bin vs. wine-bin-unstable:
notepad32, notepad32-unstable, and notepad64, notepad64-unstable once we
start providing amd64 packages. This does not make a lot of sense
because these wrapper scripts have the same contents.
>> Which leaves the laoders /usr/bin/wine, /usr/bin/wine64. For those, we
>> have a documented mechanism that is even used by the current
>> /usr/bin/wine wrapper scripts: WINELOADER can be set to select which
>> wine version is actually used on a per-user or even a per-invokation
> That's a wine-specific solution. The alternatives system is debian's
> system-wide solution to this problem, which we should use for
I don't see how the alternatives system is a solution for any problem.
My main problem is that the system imposes the administrator's (or the
package maintainers') choice on every user in a multi-user setup and
for every program invocation. It doesn't even work for simple things as
"editor", "pager", "browser", that's why there are /usr/bin/sensible-$X
wrappers for those. These scripts use environment variables (EDITOR,
VISUAL, PAGER, BROWSER), enabling the user to override Debian's or their
system administrator's default choices.
If you want give users a choice in what wine version they want to use,
system-wide alternatives are not the answer. Providing a wrapper script
that uses an environment variable is. And from looking at the Wine
sources as provided by upstream, I have come to the conclusion that this
exactly what the WINELOADER variable is intended for.
More information about the pkg-wine-party