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

Re: Depend on a package from an other arch



On 17/08/15 00:48, Wookey wrote:
> +++ Bertrand Marc [2015-08-13 09:42 +0200]:
>> I am trying to fix Debian bug #783875 [1]: playonlinux (which is arch
>> independant) should depend on the 32 bits version of wine. Therefore I
>> added a dependency on wine32|wine32-development, but it seems the
>> package will not migrate to testing [2], because wine32 is not available
>> on amd64.

Unless things have changed since
<https://lists.debian.org/debian-devel/2013/11/msg00007.html>, the only
way to do this is to depend on a package not available in your
architecture, and when it would otherwise migrate, ask the release team
to force it into testing.

> So playonlinux should depend on wine32 for arches where it exists
> (which is i386, kfreebsd-i386, and powerpc)? But on 64-bit arches it
> should depend on wine32:<some foreign arch>? should playonlinux on
> ppc64el depend on wine32:powerpc?

playonlinux is a frontend for running specific proprietary Windows
applications (mostly games, hence its name) with an appropriate set of
workarounds, native Windows DLLs and potentially patches to Wine to make
them work. It shouldn't support powerpc unless it knows about specific
proprietary applications that can be run on powerpc, which in practice
seems unlikely: the vast majority of Windows software is only available
on x86 (and most of that has historically been 32-bit).

>> I thought I should instead add a dependency on wine32:any |
>> wine32-development:any and ask the wine maintainer to move to
>> multiarch:allowed. 

You don't need to add :any for a cross-architecture dependency, because
wine32 is already Multi-arch: foreign.

Using amd64 with an i386 foreign architecture as an example, the
possible multi-arch categories are:

Architecture: i386, not Multi-arch (the implicit default):
    - can satisfy i386 packages' dependencies
    - cannot satisfy amd64 packages' dependencies
    - cannot be co-installed with its amd64 equivalent

Architecture: i386, Multi-arch: same:
    - can satisfy i386 packages' dependencies
    - cannot satisfy amd64 packages' dependencies
    - *can* be co-installed with its amd64 equivalent

Architecture: i386, Multi-arch: foreign:
    - can satisfy i386 packages' dependencies
    - *can* satisfy amd64 packages' dependencies
    - cannot be co-installed with its amd64 equivalent

Architecture: i386, Multi-arch: allowed:
    - can satisfy i386 packages' dependencies
    - can satisfy amd64 packages' dependencies but only if they are
      decorated with :any
    - cannot be co-installed with its amd64 equivalent

M-a: allowed is designed for interpreters like Perl and Python, where
some packages depending on the interpreter (compiled
extensions/libraries) need to be installed for the same architecture as
the interpreter, but some packages (those that just run the interpreter
as a program) don't care which architecture the interpreter is.

> So far
> as I know wine and cross-compilers are the only two areas where
> explicit cross-arch dependencies are appropriate, but there may be a
> couple of others. 

Transitional packages from lib32nss-whatever to libnss-whatever:i386 are
another situation where this would have been appropriate, although in
practice most (all?) of these already worked around lack of archive
support for explicit cross-arch dependencies by using an intermediate
package.

    S


Reply to: