On 2018/05/21 13:21, Paul B. Henson wrote:
> > From: Stuart Henderson
> > Sent: Monday, May 21, 2018 1:49 AM
> > > - the versionning of the modules feels 'wrong', and should be fixed
> > > within the build system.
> >
> > yes, there's definitely something wrong there.
>
> No disagreement from me :), but as I'm not much of an expert in the ports
> build system, any suggestion on how to better handle it?
>
> > which are the actual names used to dlopen them?
>
> I believe it will open whatever file name is specified in the configuration,
> eg
>
> moduleload accesslog.so
>
> > https://www.openldap.org/faq/data/cache/362.html)
> > suggests that .la files should be used rather than using .so files
> > directly.
>
> The wiki FAQ it is pretty dated as demonstrated by the beginning of that
> entry "As of OpenLDAP 2.0" 8-/.
>
> However, the current documentation:
>
> http://www.openldap.org/doc/admin24/slapdconf2.html#cn=module
>
> Also shows .la instead of .so; I've always used .so and never had a problem,
> but using the .la files would solve the issue of the kludgy symlink creation.
> I updated the package to install the .la files instead of making unversioned
> .so links and updated my config to use them, and that seems to work fine.
It's the upstream build system that is building them with odd
names here, ports doesn't have much to do with this.
.so files intended as dlopen'd modules should not normally have a
version in the filename anyway, there might be some missing libtool
flag. I'll see if I can figure out what's going on but am a bit
busy the rest of this week..
> > as far as I'm concerned 2.3 can be left to rot ;-)
>
> Definitely, that's been unsupported upstream for quite a while.
>
> > > - this definitely needs a current.html entry to warn people of the
>
> How involved does that need to be? Just something like "OpenLDAP now uses
> modules, be sure to add the appropriate modulepath and module configuration
> options to load the ones necessary for your configuration" or something more
> complicated?
I think basically tell users what lines to add to get the same as they
have now, then they can remove bits which they don't need.
Being realistic some people are going to upgrade, find things are broken,
then if they're lucky find the upgrade notes. So it needs to cover what
they need to know to unbreak things in a hurry ;)
> > yep, probably also patch the sample config file showing the important ones..
>
> I don't believe the current port comes with a sample config? I could add one…
The file is installed to ${PREFIX}/share/examples/openldap/slapd.conf,
that's the file where I'd add as an example. It might be worth @sample'ing
this file into ${SYSCONFDIR}/openldap as well, I think it was just an
oversight that this wasn't done before..
> --- Makefile 12 Jan 2018 00:36:28 -0000 1.161
> +++ Makefile 21 May 2018 20:18:38 -0000
> @@ -9,7 +9,7 @@ DISTNAME = openldap-2.4.45
> PKGNAME-main = ${DISTNAME:S/-/-client-/}
> PKGNAME-server = ${DISTNAME:S/-/-server-/}
> REVISION = 4
> -REVISION-server = 5
> +REVISION-server = 6
>
> # overwrite -main pkgname/path to strip FLAVOR, aci only affects the server
> FULLPKGNAME-main = ${DISTNAME:S/-/-client-/}${FLAVOR_EXT:S/-aci//}
> @@ -32,7 +32,7 @@ MAINTAINER = Stuart Henderson <sthen@ope
> # OpenLDAP Public License
> PERMIT_PACKAGE_CDROM = Yes
>
> -WANTLIB += c crypto ssl
> +WANTLIB += c crypto ltdl ssl
Here you're adding to the WANTLIB which is used for both -server and
-main, so REVISION needs bumping for both (just get rid of REVISION-server
and set REVISION=6).
> .if ${FLAVOR:Maci}
> -CONFIGURE_ARGS += --enable-aci
> +CONFIGURE_ARGS += --enable-aci=mod
> .endif
hmm, with aci turned into a module, we should be able to get rid
of the FLAVOR. (and even if we can't, it'll need an extra PFRAG for
aci otherwise the files won't be installed).
