On Mon, Aug 20, 2012 at 12:37:32PM -0700, Russ Allbery wrote: > We don't have a particularly good way of handling this situation right now > other than one-off work on each package that may need to be treated > unusually. It's a bit difficult for the maintainer to determine the > implications for the dependency graph, and there isn't any good way to > exclude all packages in a particular class from a particular architecture.
It's not that hard. Something like «dak rm -n -R -b -a s390 -s unstable pciutils libpci3» on ries (the DD-accessible ftp-master mirror). However this does not recurse, so you need to add the resulting packages to the RM or look if those listed can be fixed by dropping the Build-Dependency. > We have some architectures where I really doubt that anyone is using them > for anything other than a server (s390, for instance), and (modulo cases > where it makes sense to run such software as part of a remote session on a > shared-user system) [...] People once said exactly that as a use case. However I'm unsure who the users of Debian s390(x) really are. And I don't know if the largest user (still?) does that. I imagine that it would work to use a mainframe as a thin client host in any case. Some blacklisting happens in P-a-s and some through BD-Uninstallable by Build-Depending on something that does not exist on that architecture. Kind regards Philipp Kern
signature.asc
Description: Digital signature
