Source: xfsprogs Version: 6.12.0-1 Severity: normal 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
