[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#798780: release.debian.org: Please let playonlinux migrate to testing



On 05/08/2016 06:16 PM, Bertrand Marc wrote:
> Le 10/04/2016 13:52, Andreas Beckmann a écrit :
>> On Sun, 21 Feb 2016 11:00:14 +0100 Bertrand Marc <beberking@gmail.com>
>> wrote:
>>> Do you think we could find a solution to restore the dependency and let
>>> playonlinux migrate to testing ?
>>
>> What about
>>
>> * split a playonlinux-data package from playonlinux containing
>>   /usr/share/playonlinux/*
>>   /usr/share/locale/*
>>   mark as Multi-Arch: foreign
>>   document in the description that a foreign architecture may be needed
>>   to install playonlinux on amd64 (dpkg --add-architecture i386)
>>
>> * make playonlinux arch:any
>>   Depends: playonlinux-data (= ${source:Version})
>>
>> * add Build-Depends: wine32 | wine32-development
>>   (instead of enumerating the architectures in the playonlinux package)

I assume both packages are part of src:playonlinux, and playonlinux-data
is arch:all?
But why "Multi-Arch: foreign" for playonlinux-data then?

Otherwise (playonlinux-data arch:any, and src:playonlinux build-depends
on wine32) no playonlinux* package at all would be on e.g. amd64. So
users would see no playonlinux* package, and thus they wouldn't see the
documentation to install the foreign arch.

But even if playonlinux-data is available on amd64, I doubt that the
documentation in the long package description is enough. Remember that
POL is intended to give a quick and easy start. A part of its target
audience might not even know that long package descriptions exist.

So this solution makes sure that POL works *once* it's been installed.
But it doesn't help greatly to install it.


Alternatively you could make something similar to what we have in the
wine packaging.

There wine (arch:all) depends on wine32|wine64 (which are arch specific,
and only available on archs with the correct 32-/64 bitness).
Installations without wine32 are considered broken generally, but there
are some use cases that work without wine32. I think the same is true
for POL: you generally want wine32, but you don't need it in *every* case.

So:

* Keep a dependency from playonlinux on "wine|wine-development".
  Nowadays these packages provide the /usr/bin/wine(-development)
  and /usr/bin/wineserver(-development) wrappers/links, it's not an
  empty package as stated elsewhere.

* Make playonlinux (arch:all) *recommend* wine32|wine32-development.
  This /should/ solve the release migration issue.

* Change /usr/bin/playonlinux to be a wrapper script that checks
  if wine32 is installed (test if the executables /usr/lib/wine/wine
  or /usr/lib/wine-development/wine exist).
  If yes, execute the real playonlinux.
  If no, give the user instructions how to install wine32. If you
  think wine32 is needed in any case, you'd have to abort now.
  Otherwise just continue after displaying the warning.
  Wine shows the warning only in the terminal. I think POL would
  have to use something like zenity (we had that in Wine once, but
  it was removed for reasons unknown to me).

* Additionally you might add the same test/warning to the postinst
  as suggested in https://bugs.debian.org/783875#44.

* Also additionally you might add the instructions to install wine32
  from i386 in the description (as Andreas suggested). I don't know
  why we don't have that in Wine.

You  probably need some versioning for the wine dependencies. I can help
with them (and the other changes) if you want to pick this route.

For reference the /usr/bin/wine(-development) wrapper script:
http://anonscm.debian.org/cgit/pkg-wine/wine.git/tree/debian/scripts/wine

Greets
jre


Reply to: