Bug#894297: [PATCH] cyrus-sasl2: please add build-profile support

[Karsten Merker]

Package: cyrus-sasl2
Version: 2.1.27~101-g0780600+dfsg-3
Severity: wishlist
Tags: patch
X-Debbugs-CC: debian-riscv at lists.debian.org
User: debian-riscv at lists.debian.org
Usertags: riscv64

Hello,

we are in the process of bootstrapping a Debian port for the
riscv64 architecture (https://wiki.debian.org/RISC-V). The
cyrus-sasl2 package is part of the build-dependency chain for the
essential package set, so we need to build it to be able to
complete the bootstrap process.

Cyrus-sasl2 is involved in a circular dependency chain whose
untangling requires building the package in multiple steps with
reduced functionality and reduced build-dependencies.  To achieve
that, debian/rules currently supports passing a number of options
(no-sql, no-ldap and no-gssapi) in $(DEB_BUILD_OPTIONS).  This
mechanism has the limitation that it requires manually adjusting the
build-dependency list based on the options set and makes it hard to
autobuild the package in a bootstrapping context.  The use of
build-profiles (https://wiki.debian.org/BuildProfileSpec) would make
this process quite a bit easier.  Attached is a patch that adds
build-profile support to the packge while keeping the original
$(DEB_BUILD_OPTIONS)-based mechanism in place.

The build profile names follow the "extension namespace" conventions
from the build profile specification:

DEB_BUILD_OPTIONS -> build-profile name
-----------------------------------------
no-sql            -> pkg.cyrus-sasl2.nosql
no-ldap           -> pkg.cyrus-sasl2.noldap
no-gssapi         -> pkg.cyrus-sasl2.nogssapi

It would be very helpful for our bootstrapping efforts if you could
upload a version of the cyrus-sasl2 package with this patch applied to
unstable in the near future.  For a standard build the patch changes
nothing, so there should be no significant risk in applying it.

JFTR one thing that I have found while testing the patch: the three
options/profiles are in practice not completely independent from each
other.  The main purpose of the no-gssapi option is to remove the
dependency on kerberos, but if the package is built with SQL support
(i.e. pkg.cyrus-sasl2.nogssapi is set but pkg.cyrus-sasl2.nosql is
not), libpq5 by default pulls in krb5 nonetheless.  The same limitation
applies to the existing mechanism, so this isn't a regression compared
to what we have now.  It definitely makes sense to have separate
options/profiles for no-gssapi and no-sql though, as postgresql
supports a stage1 build without krb5 for bootstrapping purposes and in
this case they are really independent from each other.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cyrus-sasl2-build-profile.patch
Type: text/x-diff
Size: 4439 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-cyrus-sasl2-debian-devel/attachments/20180328/90a5f530/attachment.patch>