Re: Dependencies across architectures
On 01/07/2018 05:39 PM, Wookey wrote:
> On 2018-01-07 19:23 +0800, Paul Wise wrote:
>> On Sun, Jan 7, 2018 at 5:59 PM, Ole Streicher wrote:
>>
>>> If we take Multi-Arch serious, this shouldn't be the case, right?
>>
>> I guess the release team might accept patches to britney for this but
>> I've also a vague memory that they prefer arches to be self-contained.
>
> This issue affects so few packages that no-one has put in the effort
> to make this (automatic migration with cross-arch dependencies) work.
> I talked about it with respect to doing this for cross-compilers and
> they were OK with doing this properly this so long as there was a good
> reason (but in the end cross-compilers were done a different way so
> there was no need). In the meantime there is a rather hacky whitelist
> for the few packages that do need this (basically wine IIRC).
As *workaround* for this problem you might use some wrapper:
Indeed Wine is closely related to this issue, but we solved the problem
in another way: Wine needs some architecture specific packages which are
only available on either 32-bit or 64-bit. So our common case on amd64
is that we need to depend on a i386 package.
However we don't use any hard cross-architecture dependencies (any
more?), only "soft" cross-architecture dependencies: either Depends
with an alternate package from the same architecture, or Recommends. In
our case:
wine (arch:all)
depends:
wine32 (only 32-bit archs) | wine64 (only 64-bit archs)
We additionally have a wrapper script /usr/bin/wine (in wine) for the
main Wine binary (in wine32). It gives a warning on console with
instructions how to install the foreign package wine32. Using
wine64-only is possible, but in most cases wine32 is also wanted. So
just warning on console, but still trying to run Wine, fits our needs
quite good.
Another affected package is playonlinux. Its users rely on wine32 even
more then Wine users, so its maintainer would like to depend on wine32
(see: #798780). For now he chose to just depend on wine, but afaik
plans to add some wrapper with a warning if wine32 is missing. This
would need to be a graphical one, maybe using zenity.)
I don't know if lowering the dependency to recommends and using a
wrapper script would be a good solution for pyraf. Assuming "iraf" is
absolutely required to make use of the application, that would mean in
the wrapper you'd need an error message which aborts (and not only warns
as in Wine's case). Thus one could argue that python3-pyraf is buggy
because it lacks the Depends on iraf. Counterargument would be that the
wrapper exits cleanly and at least gives _instructions_ how to add a
foreign arch and what to install then.
Greets
jre
Reply to: