Your message dated Fri, 2 Sep 2022 12:03:55 +1000 with message-id <[email protected]> and subject line Re: Bug#761933: Using libroken through heimdal-multidev has caused the Debian Bug report #761933, regarding heimdal-multidev: Making libroken easier for other packages to use to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 761933: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761933 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: heimdal-multidev Version: 1.6~rc2+dfsg-8 Severity: wishlist OpenAFS is starting the process of creating a new stable release branch, and the new branch will have dependencies on libroken and libhcrypto (hcrypto will be covered separately). Upstream OpenAFS bundles copies of roken and hcrypto, but for Debian it is presumably better to use the system's version instead. Upstream has nominal support for using external roken (though not, at present, hcrypto) in the form of a configure argument --with-roken=DIR. However, the implementation of the configure check just attempts to set CPPFLAGS+=-I${DIR}/include and LDFLAGS+=-L${DIR}/lib, which would require the use of heimdal-dev instead of heimdal-multidev. Given the other packages I comaintain, it would be highly inconvenient to have heimdal-dev installed to work on openafs, so I am interested in ways to get openafs working with only heimdal-multidev. I do not see any real way around this that does not involve some changes to upstream openafs, but it might be easier if there was (e.g.) a pkg-config file for libroken. I suppose a separate libroken-dev package would suffice for my purposes, but might be quite awkward from your perspective. Do you have any thoughts on this matter? When I started writing this feature request, I thought there were some symbols required by openafs that were not provided by the current libroken18-heimdal-1.6~rc2+dfsg-8, but I no longer believe that is the case. So, it's just the question of how to hook the system libroken into the openafs build, which is patchable in openafs if nothing else. Please close this bug if you don't think there is anything reasonable that can be done on the heimdal side to support this use case. Thanks, Ben -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libroken18-heimdal depends on: ii libc6 2.19-11 ii multiarch-support 2.19-11 libroken18-heimdal recommends no packages. libroken18-heimdal suggests no packages. -- no debconf information
--- End Message ---
--- Begin Message ---On Thu, Sep 01, 2022 at 11:32:34PM +0100, Jelmer Vernooij wrote: > The main motivator here was Samba, but it has also gone into the other > direction on this - basically just vendoring in a copy of Heimdal, > rather than linking against system Heimdal. Sounds like this isn't required anymore. Closing. -- Brian May <[email protected]>
--- End Message ---
