Hi all, Sorry for the delayed response to this thread. I ran out of time yesterday.
On Mon, 13 Nov 2017 11:58:04 -0500, Sam Hartman wrote: > so, why don't you take this opportunity to try and sell me on how cool > multi-arch is for krb5 dev packages and why it provides Debian with neat > enough capabilities that I want to commit to supporting it. Off the top of my head: 1. Multi-arch support in krb5-multidev is primarily needed for cross-compiling packages without requiring the use of a chroot, lxc or similar method. A lack of multi-arch co-installability for krb5-multidev makes building packages such as 32-bit Wine on 64-bit systems more difficult. (Okay, so the libraries can be installed manually... but it's more of a hassle). This lack of support is also another build-dep that cannot be satisfied. 2. Debian is now making a concerted effort to provide multi-arch installable development packages, now that most of the binary packages are fully supported in this way. 3. Almost all of the krb5 set of packages are already multi-arch installable. Why not go the whole way and do this properly? On Mon, 13 Nov 2017 10:51:10 -0800, Russ Allbery wrote: > Removing this option will break krb5-multidev. Sorry about that. I didn't realise how krb5-multidev was installed to allow heimdal-multi-dev to be co-installed. On Mon, 13 Nov 2017 14:59:03 -0800, Russ Allbery wrote: > Sam Hartman <hartm...@debian.org> writes: >> we do ship a pkg-config script and that handles this correctly. >> How does pkg-config figure out which arch you're building for? > pkg-config the command appears to have the same problem. It embeds a > compile-time path of pkgconfig directories to search for build options, >which is based on the architecture for which pkg-config is built: Developers need to use PKG_CONFIG_PATH or PKG_CONFIG_LIBDIR to tell pkg-config which arch is the target. There was also a push to add a --host option some while ago, but I'm not sure where that's up to. Looking forward, I think we're all agreed that pkg-config is the correct solution. That said, my preferred solution is to drop krb5-config.mit. (Packages such as icu and freetype are also removing their legacy -config interfaces.) However, as Russ pointed out, this approach is a breaking change (until maintainers update their packages, at least). So drawing on another of Russ' posts, I'd like to propose that we split krb5-config.mit into a separate package (krb5-multidev-bin or similar). This new package would only expose one architecture, but that would be sufficient for most people using the legacy interface. Splitting the package would avoid the multi-arch conflict caused by krb5-config.mit and allow krb5-multidev to become Multi-Arch: same. libkrb5-dev could also become M-A: same, if the krb-config symlink was moved to krb5-multidev-bin.
