Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Hugh McMaster]

On Wednesday, 10 January 2018 2:32 AM, Sam Hartman wrote:
> Hugh> This seems to work well for development on the host
> Hugh> architecture and when setting CC="gcc -mXX". It may not work
> Hugh> so well for cross-compiling, where some packages set
> Hugh> CC_FOR_BUILD, BUILD_CC or some other random variable.
>
> In the GNU model, I think that's the wrong thing to do.
> I also note that every solution we've discussed has this defect.

That's a good point. The -config scripts were only ever intended 
for use on native (build = host) architecture. So we shouldn't 
try to fix krb5-config.mit for this purpose.

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Sam Hartman]

> "Hugh" == Hugh McMaster  writes:

Hugh> Hi Sam, Apologies for the delay in replying. Somehow your
Hugh> message landed in my spam folder.

Hugh> On Friday, 5 January 2018 1:44 PM, Sam Hartman wrote:
>> My plan is to use the following: CC=${CC-cc} tripple=`$CC
>> -print-multiarch 2>/dev/null|| ( $CC -dumpmachine | sed 's/-pc//'
>> )` if [ x$tripple = x ]; then     echo >&2 Failed to find
>> installation architecture     exit 2 fi

Hugh> This seems to work well for development on the host
Hugh> architecture and when setting CC="gcc -mXX". It may not work
Hugh> so well for cross-compiling, where some packages set
Hugh> CC_FOR_BUILD, BUILD_CC or some other random variable.

In the GNU model, I think that's the wrong thing to do.
I also note that every solution we've discussed has this defect.

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Hugh McMaster]

Hi Sam,

Apologies for the delay in replying. Somehow your message landed in my spam 
folder.

On Friday, 5 January 2018 1:44 PM, Sam Hartman wrote:
> My plan is to use the following:
> CC=${CC-cc}
> tripple=`$CC -print-multiarch 2>/dev/null|| ( $CC -dumpmachine | sed 
> 's/-pc//' )`
> if [ x$tripple = x ]; then
>     echo >&2 Failed to find installation architecture
>     exit 2
> fi

This seems to work well for development on the host architecture and when 
setting CC="gcc -mXX". It may not work so well for cross-compiling, where some 
packages set CC_FOR_BUILD, BUILD_CC or some other random variable.

That said, I'd hope that cross-compilers make use of pkg-config instead of 
krb5-config.mit.
Plus, cross-compiling with krb5-config.mit was impractical, due to the 
hard-coded
libdir path.

I was going to suggest calling `dpkg-architecture -qDEB_HOST_MULTIARCH`, as the
cups team did recently to solve a similar problem in cups-config [1]. But that 
would 
add a dependency on dpkg-dev, which may not be desirable. (And, again, there is 
no
support for cross-compiling).

> Expect an upload shortly; let me know how it works for you.
I see you're taking a trip through the NEW queue. So I'll need to wait for the 
package 
to land in Sid before I can see how you've integrated the code.

Thanks for your work on this. (And to Ben and Russ as well.)

Hugh

[1] 
https://anonscm.debian.org/cgit/printing/cups.git/commit/?id=3814f6fdb9f4edcdd841a38fcea18c223f155dea

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Sam Hartman]

Hi.

I like the approach of  making krb5-config not dynamic, but I'd prefer
to discover the behavior of the compiler rather than to  base our
interactions on its filename.


My plan is to use the following:
CC=${CC-cc}
tripple=`$CC -print-multiarch 2>/dev/null|| ( $CC -dumpmachine | sed 's/-pc//' 
)`
if [ x$tripple = x ]; then
echo >&2 Failed to find installation architecture
exit 2
fi


Expect an upload shortly; let me know how it works for you.

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Hugh McMaster]

These are all valid points. But my attempt above was a proof-of-concept of
a different solution focused on pkg-config. It's nowhere near production-ready.

Still, your email got me thinking that we seem to be making this too
complicated. Since the hard-coded libdir path is the problem, wouldn't be 
it better to make the libdir output dynamic?

A very quick hack (without handling -mXX, $CFLAGS or PATH):

#!/bin/sh
env_cc=$(printenv CC)

case $env_cc in
"gcc")
triplet=`$CC -print-multiarch`
;;
*"-gcc"*)
triplet=`$CC -print-multiarch`
;;
"clang")
triplet=`$CC -dumpmachine | sed 's/-pc//'`
;;
*)
echo "FIXME..."
esac

echo "-L/usr/lib/$triplet/mit-krb5"

This allows 'gcc', 'clang' or long gcc binaries (e.g. x86_64-linux-gnu or 
arm-linux-gnueabi-gcc-7)
to output a usable libdir.

Ultimately, such a solution, if expanded, is temporary until we can move to 
pkg-config
(if that is desired, of course).

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Sam Hartman]

So, I finally got a chance to look at this.
It sounds like you're taking a significantly different approach than we
had discussed earlier.

What we had talked about is parsing the output of $CC.  For example
asking gcc what tripple it was built for and going from there.

But what you did is assume that the gcc path encodes the tripple with
the special case of supporting -m32 assuming that it is the first option
in $CC (and not say in $CFLAGS).

It looks like this was probably a bit easier to code, but looks like it
has the following weaknesses:

* Assumes that -m64 is always on a x86_64 system rather than using gcc
-m64 to build for x86_64 on an 686 system.

* assumes that -m32 and -m64 are only used on x86 architectures

* Mishandles setups where rather than set all the compiler variables, a
  directory including cross tools is prepended to PATH

Are there advantages beyond implementation simplicity over what we
talked about previously?

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Sam Hartman]

As you can tell I did not get around to looking at this last weekend.
The US holiday ended up taking up more time than I anticipated, and then
I got sick.  This week my day job is taking up all my time; hope to have
some Debian cycles next week.

--Sam

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Hugh McMaster]

On Monday, 20 November 2017 11:07 AM, Sam Hartman wrote:
> Why do you want to replace krb5-config with pkg-config?
> [...]
> Are there advantages/simplicities in coding that led you to that
> approach?  I'd like to understand so I can evaluate.

As Ben pointed out, pkgconfig has been replacing the -config 
interfaces for some time, so I generally consider the -config
scripts to be deprecated or legacy at best. Also, the output
of these scripts can be unreliable or even entirely incorrect
(e.g. when cross-compiling).

I wrote the script using pkg-config because I wanted to
see if pkg-config-crosswrapper could solve the 
cross-compiling issue. That said, I think the script I posted
above is simpler than calling arch-specific config files
from a krb5-config wrapper. But that's not saying
my solution is any better.

> i'm a bit concerned that getting the behavior of all the different
> --libs options for the different types of Kerberos apps will be a bit
> fiddly.

There are several pkg-config files in /usr/lib//pkgconfig/mit-krb5
that may be useful. However, to use them, you must either set 
PKG_CONFIG_LIBDIR to the pkgconfig/mit-krb5 directory, or move 
the files into the main pkgconfig directory.

Unfortunately, this latter option would conflict with the 
pkgconfig files from heimdal-dev. Of course, this only matters if users
install both package variants. Is this likely?

The MIT pkgconfig files could potentially be prefixed with mit-, like 
mit-krb5.pc and mit-krb5-gssapi.pc already are. Since it seems that
most, if not all, developers still use krb5-config(.mit), this may be a better 
option.

Hugh

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Benjamin Kaduk]

On Sun, Nov 19, 2017 at 07:07:45PM -0500, Sam Hartman wrote:
> 
> Why do you want to replace krb5-config with pkg-config?
> That seems like a good option if we can sell upstream on the idea, but
> something requiring more thought otherwise.

I believe we can consider upstream sold.

pkg-config is the de facto standard for how to do this sort of
thing, and there is no need for krb5 to be its own special snowflake
anymore.  pkg-config also gives more reasonable behavior with
private libraries and static linking, if I remember correctly.

-Ben

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Sam Hartman]

Thanks.
I'll take a look next week.
This looks very promising.
Unless I'm missing something, I think you've done a lot of the work
regardless of whether we want to wrap krb5-config architecture scripts
or wrap a script that calls cross-pkg-config.


Why do you want to replace krb5-config with pkg-config?
That seems like a good option if we can sell upstream on the idea, but
something requiring more thought otherwise.

Are there advantages/simplicities in coding that led you to that
approach?  I'd like to understand so I can evaluate.

less good options
i'm a bit concerned that getting the behavior of all the different
--libs options for the different types of Kerberos apps will be a bit
fiddly.

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Hugh McMaster]

On Friday, 17 November 2017 7:26 AM, Sam Hartman wrote:
> Also, if we're moving away from krb5-config, the only strong requirement
> is that krb5-config work correctly on the native architecture.
> We'd like it to work in other cases, but if we're OK telling people who
> are cross-compiling to use pkgconfig then it's OK if krb5-config is
> imperfect.
> While I think we can do better, even just having unqualified
> krb5-config.mit be for the native architecture would not make things
> worse than today.

I spent some time looking into this today, and I think it's worth pointing out
that pkg-config can produce the correct library path if invoked using
pkg-config-crosswrapper, e.g. i686-linux-gnu-pkg-config.

This raises the possibility that krb5-config could become a wrapper script
for pkg-config, rather than a wrapper for arch-specific krb5-config scripts.

With this in mind, I wrote a proof-of-concept script for testing. It's not
perfect by any means, but it's one way of moving forward.

The script relies on CC being set in the shell environment.

--
Hugh McMaster

krb5-pkg-config
Description: krb5-pkg-config

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Sam Hartman]

> "Russ" == Russ Allbery  writes:

>> But how can we link this output to CC?

Russ> That's a trickier question, since I'm not sure Autoconf or
Russ> make alway exports the current compiler as the CC environment
Russ> variable in all the ways krb5-config is called now.  But at
Russ> least we do have a fighting chance of picking up the correct
Russ> compiler, and worst case we fall back to the default compiler.

Also, if we're moving away from krb5-config, the only strong requirement
is that krb5-config work correctly on the native architecture.
We'd like it to work in other cases, but if we're OK telling people who
are cross-compiling to use pkgconfig then it's OK if krb5-config is
imperfect.
While I think we can do better, even just having unqualified
krb5-config.mit be for the native architecture would not make things
worse than today.

--Sam

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Russ Allbery]

Hugh McMaster  writes:

> What about just calling clang like this?
> clang -dumpmachine | sed 's/pc-//'

That might work, although it would need some verification that this
produces the right result on all of Debian's architectures.  (So do mine,
for that matter, although the one based on libpath is pretty much
guaranteed to work because otherwise the compiler wouldn't work properly.)

> But how can we link this output to CC?

That's a trickier question, since I'm not sure Autoconf or make alway
exports the current compiler as the CC environment variable in all the
ways krb5-config is called now.  But at least we do have a fighting chance
of picking up the correct compiler, and worst case we fall back to the
default compiler.

-- 
Russ Allbery (r...@debian.org)   

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Hugh McMaster]

On Thursday, 16 November 2017 10:16 AM, Russ Allbery wrote:
> gcc -print-multiarch will give you what I think is the path component we
> use, although I'm not 100% sure that we always use that value.

> I don't see an equivalent for clang, but:
>clang -print-search-dirs | sed 's/:/\n/g' | egrep '^/lib/[^/]+$' | sed 
> 's%.*/%%'
should do it.

What about just calling clang like this?
clang -dumpmachine | sed 's/pc-//'

But how can we link this output to CC?

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Russ Allbery]

Sam Hartman  writes:

> I'd rather find a more clever solution.
> Is there any way to map back from CC to something useful as an
> installation architecture?
> I'd prefer something that worked both for gcc and llvm.

gcc -print-multiarch will give you what I think is the path component we
use, although I'm not 100% sure that we always use that value.

I don't see an equivalent for clang, but:

clang -print-search-dirs | sed 's/:/\n/g' | egrep '^/lib/[^/]+$' | sed 's%.*/%%'

should do it.

> My hope is to do something like

> * install krb5-config.mit

> * have that be a script that calls krb5-config.mit.tripple

> * Each package only includes krb5-config.mit.tripple for the appropriate
>   architecture.

Yeah, I was trying to figure out how to make something like that work, and
I think that might be the best approach.

-- 
Russ Allbery (r...@debian.org)   

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Sam Hartman]

Unfortunately, krb5-config is used fairly widely by software not in
Debian.
In the past krb5 has been fairly conservative, which in this case would
mean having krb5-multidev depend on krb5-multidev-bin for a release.
If we did that we would have a solution for buster+1 to make
krb5-multidev m-a installable.

Obviously we could be less conservative here.

I'd rather find a more clever solution.
Is there any way to map back from CC to something useful as an
installation architecture?
I'd prefer something that worked both for gcc and llvm.

My hope is to do something like

* install krb5-config.mit

* have that be a script that calls krb5-config.mit.tripple

* Each package only includes krb5-config.mit.tripple for the appropriate
  architecture.

If we can make that work, does that make people happy?
Do we have any thoughts on how to make that work?

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Hugh McMaster]

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  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.

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Russ Allbery]

Sam Hartman  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:

lothlorien:~$ strings /usr/bin/pkg-config | grep /pkgconfig
/usr/local/lib/x86_64-linux-gnu/pkgconfig:/usr/local/lib/pkgconfig:/usr/local/share/pkgconfig:/usr/lib/x86_64-linux-gnu/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig

So the Debian package containing pkg-config the binary can't really be
multiarch, and it will return whatever flags are appropriate for building
a native binary on the architecture for which it was built.

pkgconfig the Autoconf system can use config.guess and related Autoconf
machinery to know the target architecture and then use the correct
pkgconfig files for that architecture, although I haven't played with it
enough to know exactly how (or if) that's wired together.

-- 
Russ Allbery (r...@debian.org)   

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Sam Hartman]

control: tags -1 -patch
control: severity -1 wishlist


> "Russ" == Russ Allbery  writes:

Russ> Hugh McMaster  writes:
>> The packages krb5-multidev and libkrb5-dev are not multi-arch
>> installable.

>> A diff of the i386 and amd64 variants of krb5-multidev reveals a
>> file conflict in /usr/bin/krb5-config(.mit).

>> The -L$libdir option causes this conflict, due to the hard-coded
>> /usr/lib/ path.

>> On Debian, this path is not needed to link with libraries in
>> /usr/lib/. So I have attached a patch removing this
>> option, 
Russ> Removing this option will break krb5-multidev.  It will no
Russ> longer be possible to build software against MIT Kerberos with
Russ> only krb5-multidev but not libkrb5-dev installed, which is the
Russ> whole point of krb5-multidev.

In particular, it is not -L /usr/lib/triplet, but
/usr/lib/triplet/mit-krb5, which for obvious reasons is not included by
default in the Debian linker.

Russ, I'm feeling really embarrassed that I didn't notice wthis.


Russ> I'm not sure how best to fix this other than no longer using
Russ> krb5-config and shipping a pkgconfig script or something.

we do ship a pkg-config script and that handles this correctly.
How does pkg-config figure out which arch you're building for?

I wonder if there is some way we can detect what arch to use from what
CC is set to.

Eventually we may get to a place where we can remove krb5-config from
krb5-multidev and depend on pkgconfig, but as Russ hints I don't think
we are there today.

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Russ Allbery]

Benjamin Kaduk  writes:
> On Mon, Nov 13, 2017 at 10:51:10AM -0800, Russ Allbery wrote:

>> I'm not sure how best to fix this other than no longer using
>> krb5-config and shipping a pkgconfig script or something.  One could
>> move the krb5-config script into an architecture-specific directory,
>> but that just moves the problem to a different area (how to find the
>> right krb5-config script to use).

> Upstream started shipping a pkgconfig script a couple releases ago.  I
> forget whether we do and/or need to patch it to match our configuration.

That's great news and is probably the best path going forward.  pkgconfig
is really the correct solution to this problem (or as close to correct as
the C build ecosystem has today).

Unfortunately, it's also a transition for everything else that links
against Kerberos libraries, and the sort of transition that will probably
never be finished.  :(  For instance, several of my orphaned Kerberos
packages, for which I don't intend to make another release, rely on
krb5-config and don't know about the pkgconfig approach to finding
Kerberos libraries.

That said, Debian could decide to just only support pkgconfig and not
krb5-config.  I'm not sure how disruptive of a change that would be.

Or put krb5-config into a separate package that's not multiarch.

-- 
Russ Allbery (r...@debian.org)   

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Benjamin Kaduk]

On Mon, Nov 13, 2017 at 10:51:10AM -0800, Russ Allbery wrote:
> 
> I'm not sure how best to fix this other than no longer using krb5-config
> and shipping a pkgconfig script or something.  One could move the
> krb5-config script into an architecture-specific directory, but that just
> moves the problem to a different area (how to find the right krb5-config
> script to use).

Upstream started shipping a pkgconfig script a couple releases ago.
I forget whether we do and/or need to patch it to match our configuration.

-Ben

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Russ Allbery]

Hugh McMaster  writes:

> The packages krb5-multidev and libkrb5-dev are not multi-arch installable.

> A diff of the i386 and amd64 variants of krb5-multidev reveals
> a file conflict in /usr/bin/krb5-config(.mit).

>   -libdir=${prefix}/lib/i386-linux-gnu/mit-krb5
>   +libdir=${prefix}/lib/x86_64-linux-gnu/mit-krb5

> The -L$libdir option causes this conflict, due to the hard-coded
> /usr/lib/ path.

> On Debian, this path is not needed to link with libraries in
> /usr/lib/. So I have attached a patch removing this
> option, but keeping -Wl,-z,relro in the output.

Removing this option will break krb5-multidev.  It will no longer be
possible to build software against MIT Kerberos with only krb5-multidev
but not libkrb5-dev installed, which is the whole point of krb5-multidev.
This is common on systems where Heimdal is the primary Kerberos library.

So I'm afraid this problem cannot be fixed this way.

I'm not sure how best to fix this other than no longer using krb5-config
and shipping a pkgconfig script or something.  One could move the
krb5-config script into an architecture-specific directory, but that just
moves the problem to a different area (how to find the right krb5-config
script to use).

-- 
Russ Allbery (r...@debian.org)   

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Sam Hartman]

So, I'm uncomfortable making a long-term promise to support krb5-config
in a multi-arch environment.
Today, the multi-arch change is easy to work with.
However, it seems entirely reasonable that the recommended cppflags and
cflags  might differ between architectures, and I don't know that I want
to sign up for the work involved in supporting that long-term.

This sounds like a wishlist bug on the face of it.  But it sounds like
you view it as more important.
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.

Regardless of how convincing you are, I can apply this patch for now,
but I may label multi-arch support for the -dev packages as experimental
and subject to future removal if it proves to require more effort than
the package maintainers want to spend.

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Hugh McMaster]

Package: krb5-multidev
Version: 1.15.2-2
Severity: important
Tags: patch

Dear Maintainer,

The packages krb5-multidev and libkrb5-dev are not multi-arch installable.

A diff of the i386 and amd64 variants of krb5-multidev reveals
a file conflict in /usr/bin/krb5-config(.mit).

  -libdir=${prefix}/lib/i386-linux-gnu/mit-krb5
  +libdir=${prefix}/lib/x86_64-linux-gnu/mit-krb5

The -L$libdir option causes this conflict, due to the hard-coded
/usr/lib/ path.

On Debian, this path is not needed to link with libraries in
/usr/lib/. So I have attached a patch removing this
option, but keeping -Wl,-z,relro in the output.

The patch is based on your git repository, but creates a quilt
patch in debian/patches.

Also, I have attached patches marking krb5-multidev and libkrb5-dev
Multi-Arch: same.

Multi-arch support is needed by other projects, so please apply
the patches as soon as possible.

Thank you.



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages krb5-multidev depends on:
ii  comerr-dev  2.1-1.43.7-1
ii  libgssapi-krb5-21.15.2-2
ii  libgssrpc4  1.15.2-2
ii  libk5crypto31.15.2-2
ii  libkadm5clnt-mit11  1.15.2-2
ii  libkadm5srv-mit11   1.15.2-2
ii  libkrb5-3   1.15.2-2

krb5-multidev recommends no packages.

Versions of packages krb5-multidev suggests:
pn  krb5-doc  

-- no debconf information
From b314ec708a11cf7e4c2b27fcb657f3964701ddae Mon Sep 17 00:00:00 2001
From: Hugh McMaster 
Date: Mon, 13 Nov 2017 21:13:12 +1100
Subject: [PATCH 1/3] krb5-config: Remove libdir path to enable multi-arch
 support

Debian does not need the -L$libdir option to link with libraries
in /usr/lib/.

Signed-off-by: Hugh McMaster 
---
 0012-krb5-config-libdir.patch |   28 
 series|1 +
 2 files changed, 29 insertions(+)
 create mode 100644 debian/patches/0012-krb5-config-libdir.patch

diff --git a/debian/patches/0012-krb5-config-libdir.patch 
b/debian/patches/0012-krb5-config-libdir.patch
new file mode 100644
index 0..16d38da11
--- /dev/null
+++ b/debian/patches/0012-krb5-config-libdir.patch
@@ -0,0 +1,28 @@
+Index: debian-krb5-2013/src/build-tools/krb5-config.in
+===
+--- debian-krb5-2013.orig/src/build-tools/krb5-config.in
 debian-krb5-2013/src/build-tools/krb5-config.in
+@@ -30,7 +30,7 @@ version_string="Kerberos 5 release @KRB5
+ prefix=@prefix@
+ exec_prefix=@exec_prefix@
+ includedir=@includedir@/mit-krb5
+-libdir=@libdir@/mit-krb5
++libdir=''
+ CC_LINK='@CC_LINK@'
+ KDB5_DB_LIB=@KDB5_DB_LIB@
+ LDFLAGS='@LDFLAGS@'
+@@ -209,13 +209,12 @@ fi
+ 
+ 
+ if test -n "$do_libs"; then
+-  libdirarg="-L$libdir"
+ # Ugly gross hack for our build tree
+ lib_flags=`echo $CC_LINK | sed -e 's/\$(CC)//' \
+   -e 's/\$(PURE)//' \
+   -e 's#\$(PROG_RPATH_FLAGS)#'"$PROG_RPATH_FLAGS"'#' \
+   -e 's#\$(PROG_RPATH)#'$libdir'#' \
+-  -e 's#\$(PROG_LIBPATH)#'$libdirarg'#' \
++  -e 's#\$(PROG_LIBPATH)#'$libdir'#' \
+   -e 's#\$(RPATH_FLAG)#'"$RPATH_FLAG"'#' \
+   -e 's#\$(LDFLAGS)#'"$LDFLAGS"'#' \
+   -e 's#\$(PTHREAD_CFLAGS)#'"$PTHREAD_CFLAGS"'#' \
diff --git a/debian/patches/series b/debian/patches/series
index f6c41d60b..3a974acc3 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -9,3 +9,4 @@ debian-local/0008-Use-isystem-for-include-paths.patch
 debian-local/0009-Fix-krb5-config-paths.patch
 0010-Initial-German-translations.patch
 0011-Fix-PKINIT-cert-matching-data-construction.patch
+0012-krb5-config-libdir.patch
-- 
2.15.0

From 9146b65ca6c07029332e9881f8f4b366ad2936f4 Mon Sep 17 00:00:00 2001
From: Hugh McMaster 
Date: Mon, 13 Nov 2017 21:18:09 +1100
Subject: [PATCH 2/3] debian/control: Mark krb5-multidev Multi-Arch: same

Signed-off-by: Hugh McMaster 
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index d215db249..9f53e51f7 100644
--- a/debian/control
+++ b/debian/control
@@ -116,6 +116,7 @@ Description: MIT Kerberos key server (Slave KDC Support)
 Package: krb5-multidev
 Section: libdevel
 Architecture: any
+Multi-Arch: same
 Depends: ${misc:Depends}, libkrb5-3 (= ${binary:Version}),
  libk5crypto3 (= ${binary:Version}), libgssapi-krb5-2 (= ${binary:Version}),
  libgssrpc4 (= ${binary:Version}),
-- 
2.15.0

From 5236ca78b3c1864085c9381c32bc502ab837c998 Mon Sep 17 00:00:00 2001
From: Hugh McMaster 
Date: Mon, 13 Nov 2017 21:18:46 +1100
Subject: [PATCH 3/3] debian/control: Mark libkrb5-dev Multi-Arch: same

Signed-off-by: Hugh McMaster 
---
 debian/control | 1 +
 1 file changed, 1 i