On Mon, Jan 07, 2019 at 11:27:52PM +, Stuart Henderson wrote:
> I remembered what this was about; it wasn't an oversight, rather upstream
> strongly hinted that people should use OLC so it was deliberately removed to
> nudge people in that direction.
Yah, upstream is quite enamored of OLC 8-/
On 2019/01/08 08:05, Landry Breuil wrote:
> On Mon, Jan 07, 2019 at 11:27:52PM +, Stuart Henderson wrote:
> > Thought I'd give an update on this since I just updated openldap.
> > Sorry not what you wanted but worth writing a few words:
> >
> > On 2018/05/22 12:46, Paul B. Henson wrote:
> > >
On Mon, Jan 07, 2019 at 11:27:52PM +, Stuart Henderson wrote:
> Thought I'd give an update on this since I just updated openldap.
> Sorry not what you wanted but worth writing a few words:
>
> On 2018/05/22 12:46, Paul B. Henson wrote:
> > Okay, how about:
> >
> > "The openldap port has been
Thought I'd give an update on this since I just updated openldap.
Sorry not what you wanted but worth writing a few words:
On 2018/05/22 12:46, Paul B. Henson wrote:
> Okay, how about:
>
> "The openldap port has been updated to use dynamically loaded modules rather
> than compile everything stat
On Sun, Jul 01, 2018 at 11:54:53AM -0700, Paul B. Henson wrote:
> On Tue, Jun 26, 2018 at 08:47:03AM +0100, Stuart Henderson wrote:
>
> > Still interested, but I need to do some testing and it hasn't been high
> > enough priority to hit the top of my queue yet.
>
> Cool, thanks. No worries, just
On Tue, Jun 26, 2018 at 08:47:03AM +0100, Stuart Henderson wrote:
> Still interested, but I need to do some testing and it hasn't been high
> enough priority to hit the top of my queue yet.
Cool, thanks. No worries, just wondering; let me know when you have a
chance to look at it if you need anyt
On 2018/06/25 16:00, Paul B. Henson wrote:
> Any further interest in switching the ports openldap to modules? Or
> should I just keep my changes local?
>
> Thanks...
Still interested, but I need to do some testing and it hasn't been high
enough priority to hit the top of my queue yet.
>
> On M
Any further interest in switching the ports openldap to modules? Or
should I just keep my changes local?
Thanks...
On Mon, Jun 04, 2018 at 04:22:04PM -0700, Paul B. Henson wrote:
> Any more thoughts on this? Other changes you'd like to see or concerns
> addressed before considering incorporating
Any more thoughts on this? Other changes you'd like to see or concerns
addressed before considering incorporating it?
Thanks...
On Thu, May 24, 2018 at 03:39:38PM -0700, Paul B. Henson wrote:
> So it doesn't look like upstream is going to bite on removing the
> version numbers from the dynamical
So it doesn't look like upstream is going to bite on removing the version
numbers from the dynamically loadable modules, so here is an updated diff that
includes a patch to do so and also installs the sample config file. It doesn't
look like we can get rid of the aci flavor after all, if you try
> From: Stuart Henderson
> Sent: Tuesday, May 22, 2018 6:08 PM
>
> Very mixed opinions about this, I'm not a fan of BDB, but then MDB/LMDB is
> really meant for an OS with unified-buffer-cache, and though it works at
> the moment without (assuming the WRITEMAP option is used), it's not like
> most
It seems that the libtool flag to not create a versioned object is
"-avoid-version". It also looks like openldap already does that when
compiling under Windows (from build/top.mk):
# platform-specific libtool flags
NT_LTFLAGS_LIB = -no-undefined -avoid-version -rpath $(libdir)
NT_LTFLAGS_MOD = -no
On 2018/05/22 17:29, Paul B. Henson wrote:
> > From: Stuart Henderson
> > Sent: Tuesday, May 22, 2018 2:51 PM
> >
> > 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.
>
> It's unlike
> From: Stuart Henderson
> Sent: Tuesday, May 22, 2018 2:51 PM
>
> 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.
It's unlikely somebody would be using both bdb and mdb though; so hard
> From: Jeremie Courreges-Anglas
> Sent: Tuesday, May 22, 2018 11:36 AM
>
> 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 c
On 2018/05/22 20:35, Jeremie Courreges-Anglas wrote:
> On Mon, May 21 2018, Stuart Henderson wrote:
>
> [...]
>
> >> .if ${FLAVOR:Maci}
> >> -CONFIGURE_ARGS += --enable-aci
> >> +CONFIGURE_ARGS += --enable-aci=mod
> >> .endif
> >
> > hmm, with aci turned into a module, we should be a
> From: Stuart Henderson
> Sent: Monday, May 21, 2018 1:46 PM
>
> It's the upstream build system that is building them with odd
> names here, ports doesn't have much to do with this.
Oh, okay; I thought you were objecting to the way I was creating the symlinks
in the makefile, not the existence
On Tue, May 22, 2018 at 08:35:38PM +0200, Jeremie Courreges-Anglas wrote:
> On Mon, May 21 2018, Stuart Henderson wrote:
>
> [...]
>
> >> .if ${FLAVOR:Maci}
> >> -CONFIGURE_ARGS += --enable-aci
> >> +CONFIGURE_ARGS += --enable-aci=mod
> >> .endif
> >
> > hmm, with aci turned into a m
On Mon, May 21 2018, Stuart Henderson 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 extr
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 m
> 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
On 2018/05/21 08:05, Landry Breuil wrote:
> On Sun, May 20, 2018 at 07:43:41PM -0700, Paul B. Henson wrote:
> > This patch updates the openldap port to use modules instead of being
> > monolithic. I've been using it in production for six months or so and
> > haven't had any issues.
>
> It needs a
On Sun, May 20, 2018 at 07:43:41PM -0700, Paul B. Henson wrote:
> This patch updates the openldap port to use modules instead of being
> monolithic. I've been using it in production for six months or so and
> haven't had any issues.
It needs a bit more than that:
- the versionning of the modules f
This patch updates the openldap port to use modules instead of being
monolithic. I've been using it in production for six months or so and
haven't had any issues.
Thanks...
Index: Makefile
===
RCS file: /cvs/ports/databases/openldap
24 matches
Mail list logo
