[pkg-wine-party] Proposed package cleanups

[Michael Gilbert]

On Thu, Jan 10, 2013 at 7:19 PM, Hilko Bengen wrote:
> * Michael Gilbert:
>
>> As a general consideration, I would prefer future development to
>> happen on the master branch, which is right now the -unstable package.
>> I would like the plain wine 1.4 series to go untouched over the course
>> of jessie except to address rc issues. And if 1.6 comes out in that
>> time, then we'll of course package it as plain wine.
>
> I disagree. Once wheezy becomes stable, both the 1.4 and 1.5 branches
> should get the same kind of packaging improvements, I would especially
> like to get the multiarch feature done properly, enabling a WoW64 setup
> on linux-amd64.

I would prefer to not waste any more time on 1.4.  That to me means
trying to avoid introducing any new rc or other problematic bugs.
Let's do development on 1.5 in the early jessie cycle, and if somehow
we get suprised and 1.6 doesn't look to be coming out in time for
jessie, we can always backport the needed changes in the later part of
the development cycle.

>> Also, I think the alternatives system needs to stay.  It will need to
>> be updated to be able to support co-installable wine and wine-unstable
>> packages.
>
> If we decide to keep the alternatives system, it needs to be changed
> considerably.

Agreed.

> With co-installable 32bit and 64bit packages for a WoW64
> setup, it makes no sense to view the "binaries" (most of which are shell
> scripts anyway) as alternatives.
>
> It does not even make sense to view the 32- and 64-bit versions of the
> wine loader as alternatives: Running 32- or 64-bit executables works
> with either loader -- /usr/bin/wine or /usr/bin/wine64.
>
> Below, I have attached the currently installed alternatives (wine
> 1.4.1-4). The "32" suffix ("64" for amd64 builds) needs to go away.

I'm not concerned about 32/64 at this point.  Just wine vs. wine-unstable.

> 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.

> 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
> basis.

That's a wine-specific solution.  The alternatives system is debian's
system-wide solution to this problem, which we should use for
consistency.

> I posted this patch because it made the build system a bit easier to
> understand and modify for the WoW64-enabled packages. If you still think
> that the support for alternatives should stay, how about removing it now
> and re-adding a modified version of it after we got the big changes in
> place?

I worry a bit about introducing compatibility problems caused by
removing and reintroducing the feature.  I would rather play it more
safe and retain the feature throughout.

Best wishes,
Mike