On 2018/05/22 20:35, Jeremie Courreges-Anglas wrote:
> On Mon, May 21 2018, Stuart Henderson <s...@spacehopper.org> wrote:
>
> [...]
>
> >> .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).
>
> I see the point of using SUBPACKAGEs and shared modules instead of
> FLAVORS for aci and gssapi support. I'm not sure I see the point of
> using shared modules just because we can, especially if this implies
> mandatory config changes for all openldap users at upgrade time.
> Is there another benefit?
Some of the backends currently compiled-in are junk or examples (null,
passwd), experimental (sql - I'm not sure this can actually work without
being linked with an ODBC library), or relatively specialist (relay,
meta, dnssrv, perl, shell), I'd be pretty happy to see these removed
from the code that's normally run. Maybe some of these can just go
completely but others might occasionally be useful so a module makes
sense.
Then there are the main DB backends. These are ones where all
OpenLDAP package users will need to adapt, which makes me less sure
about splitting them off.
gssapi affects the clients too, I don't think that's a candidate for
splitting off in this way, seems it will need to remain a FLAVOR.
