[arch-dev-public] Fixing libsasl/cyrus-sasl/cyrus-sasl-plugins
Right now we have 3 standalone packages in our repositories for a package that could get built from one source: - libsasl - library and plain/login/sasldb modules, core for libldap - cyrus-sasl - saslauthd with dependency on cyrus-sasl-plugins - cyrus-sasl-plugins - all plugins not in libsasl We have several bugreports open: https://bugs.archlinux.org/task/23856 - use /dev/urandom https://bugs.archlinux.org/task/18784 - NTLM plugin missing cyrus-sasl-plugins is built with !libtool, making it impossible to load For the libtool files, I suggest adding this patch: http://patch-tracker.debian.org/patch/series/view/cyrus-sasl2/2.1.24~rc1.dfs... Then comes the actual packaging: libsasl: the SASL library and mechanisms + sasldb (core) libsasl-gssapi: GSSAPI mechanism, avoid dependency loop (core) cyrus-sasl: saslauthd and auxprop modules (extra) cyrus-sasl-sql: sql auxprop module (extra) Then the dependencies/replaces/provides: libsasl-gssapi: depends=libsasl, replaces/provides=cyrus-sasl-plugins cyrus-sasl: depends=libsasl-gssapi cyrus-sasl-sql: depends=libsasl, replaces=cyrus-sasl-plugins This shouldn't cause any breakage and dependency resolution is nearly the same as what it was before the migration. In the future, packages should depend on libsasl-gssapi instead of cyrus-sasl-plugins.
On 03/08/11 22:05, Jan de Groot wrote:
Right now we have 3 standalone packages in our repositories for a package that could get built from one source:
- libsasl - library and plain/login/sasldb modules, core for libldap - cyrus-sasl - saslauthd with dependency on cyrus-sasl-plugins - cyrus-sasl-plugins - all plugins not in libsasl
We have several bugreports open: https://bugs.archlinux.org/task/23856 - use /dev/urandom https://bugs.archlinux.org/task/18784 - NTLM plugin missing cyrus-sasl-plugins is built with !libtool, making it impossible to load
For the libtool files, I suggest adding this patch: http://patch-tracker.debian.org/patch/series/view/cyrus-sasl2/2.1.24~rc1.dfs...
Then comes the actual packaging: libsasl: the SASL library and mechanisms + sasldb (core) libsasl-gssapi: GSSAPI mechanism, avoid dependency loop (core) cyrus-sasl: saslauthd and auxprop modules (extra) cyrus-sasl-sql: sql auxprop module (extra)
If you are wanting these in one PKGBUILD, then you can not have them in multiple repos....
Then the dependencies/replaces/provides: libsasl-gssapi: depends=libsasl, replaces/provides=cyrus-sasl-plugins cyrus-sasl: depends=libsasl-gssapi cyrus-sasl-sql: depends=libsasl, replaces=cyrus-sasl-plugins
This shouldn't cause any breakage and dependency resolution is nearly the same as what it was before the migration. In the future, packages should depend on libsasl-gssapi instead of cyrus-sasl-plugins.
On Wed, 2011-08-03 at 22:18 +1000, Allan McRae wrote:
If you are wanting these in one PKGBUILD, then you can not have them in multiple repos....
cyrus-sasl/trunk/PKGBUILD: - pkgname=('cyrus-sasl' 'cyrus-sasl-sql') - package_* for all packages - all development happens here libsasl/trunk/: - svn copy from cyrus-sasl/trunk - PKGBUILD: pkgname=('libsasl' 'libsasl-gssapi') - all later changes to trunk are merged from cyrus-sasl I could provide a script for this so it makes maintenance easier. Only problem here is that it's not failsafe when someone just builds without reading anything (like what happened when blindly removing the libtool files).
participants (2)
-
Allan McRae
-
Jan de Groot