Can a pure Python package be architecture-dependent?

[Christian Kastner <debian@kvr.at>]

Hello,

While considering a possible NMU for #589995, the question (in general)
came up whether  an otherwise architecture-independent package can be
considered architecture-dependent if its features are only supported on
specific platforms.

As the most simple example, the package contains code that binds the
name LOOPBACK to whatever it expects on a given platform. The list of
platforms it supports does not include Hurd, and the package therefore
does not work there. Additionally, only on kfreebsd, the package
requires other packages -- a relationship that cannot be expressed for
an architecture-independent package according to Policy 7.1.

Policy 5.6.8 says:

  Specifying a list of architectures or architecture wildcards other
  than any is for the minority of cases where a program is not portable
  or is not useful on some architectures.

While the specific context is otherwise "any" packages, could this be
interpreted to apply to otherwise "all" packages as well? If not, what
alternatives are there to indicate that some platforms are not
supported? Would a note in the package's description be sufficient?

The downsides of changing "Architecture: all" speak against this.
However, it should be noted that a situation as presented above should
be extremely rare.


Christian