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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ca8a3c2.60...@kvr.at