cyrus-sasl2 @2.1.25_0 indirectly depends on itself via kerberos5, gnupg, openldap

[mndavidoff (Monte Davidoff)]

There is a cycle in the dependencies for cyrus-sasl2:

$ port rdeps cyrus-sasl2
The following ports are dependencies of cyrus-sasl2 @2.1.25_0+kerberos:
  openssl
    zlib
  kerberos5
    gnupg
      libiconv
        gperf
      gettext
        ncurses
        expat
      readline
      bzip2
      libusb-compat
        pkgconfig
          glib2
            xz
            libffi
            libxml2
            perl5
              perl5.12
                gdbm
        libusb
      openldap
        tcp_wrappers
        cyrus-sasl2
        db46
        icu

The problem seems to have been introduced in r94003 by adding a dependency on kerberos5 to the kerberos variant. The kerberos variant is enabled by default.

$ port rdeps cyrus-sasl2 -kerberos
The following ports are dependencies of cyrus-sasl2 @2.1.25_0:
  openssl
    zlib

[ryandesign (Ryan Carsten Schmidt)]

Ugh, fantastic... What should we do about that? cyrus-sasl2 @2.1.25 +kerberos linked with libraries provided by the kerberos5 port, so I added the dependency, not realizing the dependency loop. (I wonder why the buildbot didn't tell me about it.) Can we tell cyrus-sasl2 to not do that? If so how, and is there any negative consequence of doing so?

[mndavidoff (Monte Davidoff)]

Here are some ideas to break the dependency loop:

1. Patch the cyrus-sasl2 configure script so it will report libraries provided by the kerberos5 port are not present. The effect on the cyrus-sasl2 port will be the same as installing cyrus-sasl2 and kerberos5 from scratch before r94003: cyrus-sasl2 will be built with kerberos support, but not linked with kerberos, because kerberos5 will indirectly depend on cyrus-sasl2, but not vice-versa.
2. Build cyrus-sasl2 without kerberos support.
3. Build gnupg with ldap support disabled.
4. Change kerberos5 to depend on gnupg2 instead of gnupg, and disable ldap support in the gnupg2 configure options.
5. Build openldap without cyrus-sasl support.

I don't know which, if any, of the above would have the least impact.

[nonstop.server@…]

Cc Me!

[ghosthound]

Replying to md14-macports@…:

Here are some ideas to break the dependency loop:

1. Patch the cyrus-sasl2 configure script so it will report libraries provided by the kerberos5 port are not present. The effect on the cyrus-sasl2 port will be the same as installing cyrus-sasl2 and kerberos5 from scratch before r94003: cyrus-sasl2 will be built with kerberos support, but not linked with kerberos, because kerberos5 will indirectly depend on cyrus-sasl2, but not vice-versa.
2. Build cyrus-sasl2 without kerberos support.
3. Build gnupg with ldap support disabled.
4. Change kerberos5 to depend on gnupg2 instead of gnupg, and disable ldap support in the gnupg2 configure options.
5. Build openldap without cyrus-sasl support.

I don't know which, if any, of the above would have the least impact.

Personally I'd got with "build gnupg without ldap support" as I expect most users don't use gnupg with LDAP, and that way they're not dragging in the large beast that is OpenLDAP.

[jmroot (Joshua Root)]

Replying to ryandesign@…:

(I wonder why the buildbot didn't tell me about it.)

Gnupg is depends_build in kerberos5, and the latter was probably already built.

[pikpik.1010@…]

Cc Me!

[ecronin (Eric Cronin)]

gpg should not be a dependency of kerberos5. It looks like when the port was initially created in r11648 the intent was that MacPorts would verify the detached signature, but that never happened and that code is gone entirely from the Portfile now but the dependency remains... The kerberos source itself doesn't try to verify the signature.

[ecronin (Eric Cronin)]

r94122