xfslibs-dev contains C #defines and types (ioctls etc) to interact with
XFS filesystem.  These are not architecture-specific.

However, xfslibs-dev also contains libhandle.so symlink to libhandle.so.1
from xfsprogs.  Apparently this is the only architecture-specific item in
this library (which is just a symlink).  And this is what causes this
package to depend on xfsprogs.

And xfsprogs, besides the actual libhandle.so.1 lib, has a few interesting
dependencies.  For example, it has a perl script, xfs_scrub_all, which uses
dbus bindings (a C extension to Python).  While for this script it is
irrelevant which architecture python interpreter (and the C extension) will
be, we still have python3-dbus dependency from the native architecture.
xfsprogs package currently can't use any foreign python interpreter just due
to this single python script which is arch-agnostic.

So, back to the library: while the only interesting usage for the library
itself is just the C .h header files, it pulls in non-trivial native python
dependency.  So it can not be used for any cross-compilation.

May I suggest to move libhandle.so directly into xfsprogs please, and make
xfslibs-dev arch:all package?  Or something like that?  So if the user actually
needs to link to libhandle (are there such users?), they can depend on xfsprogs
too, not just xfslibs-dev.  But other users, who only want the headers, can
actually *use* the library?

Currently, an alternative which I'm about to implement in samba is to ship the
headers from xfslibs-dev directly within samba source.  Which is a really bad
thing to do..

Thanks,

/mjt