UPDATE: databases/openldap 2.3.39 -> 2.4.9

[Stuart Henderson-6]

On 2009/07/09 16:50, Toni Mueller wrote:
>
> Hi,
>
> On Thu, 09.07.2009 at 11:25:07 +0100, Stuart Henderson <sthen@...> wrote:
> > so; some developers need 2.3. other people need 2.4. others don't
>
> nice distinction. ;-}

well, some other people might need 2.3 too, but I know for sure there
are developers who need 2.3 (unless someone brings ldbm back to 2.4, I
suppose...). I also know developers who want 2.4.

> > mind which they have. so it seems there needs to be a way for the
> > versions to coexist in the ports tree.
>
> I don't know offhand if this is feasible, or in which ways this will
> cause problems to other ports and packages, but I'd be happy to decide
> to only ever have *one* of these packages installed on any given
> machine.

Me too, but if something pulls in 2.3 as a BUILD or LIB depend, and
something else pulls in 2.4, then bulk build machines don't have that
choice..

> I mean, having two differently versioned LDAP servers to
> service different applications that link against one or the other only,
> would be a little counter-intuitive, imho, because it defeats the
> purpose of having LDAP in the first place.
>
> I don't know what ypldap (in the main tree?) does. Maybe this has to
> influence the decision.
>
> > 1. add a -libs package, where 2.3 and 2.4 can coexist, keep the
> > original binary names in -main and -server and make them conflict.
> > so packages pulling in libraries from one or other version still work.
> > (I'm sure some third-party things will start to require 2.4 sometime..)
>
> This sounds good to me, but it also sounds like a lot of work.
>
> > 2. keep libs in -main (openldap-client) and rename the binaries,
> > e.g. slapd23, ldapsearch24, and tell people to symlink if they want
> > the "normal" names (like done with python).
>
> This would most likely be sufficient for me, at least as long as I can
> simply recompile a depending package to link against the other version
> of LDAP.

They are both about equal amounts of work, because either way we have to
deal with the libraries and teach the depending ports about the change.
It is a lot of work, and this is exactly why I haven't updated the port
yet - if it were just a case of making openldap 2.4 itself work properly,
it would probably have been committed a year ago.

I am still open to suggestions of easier ways to handle it that would
get things done more quickly, but I have thought about this quite a bit
so far and these are all I came up with..

[Henning Brauer-8]

* Stuart Henderson <sthen@...> [2009-07-09 21:14]:
> Me too, but if something pulls in 2.3 as a BUILD or LIB depend, and
> something else pulls in 2.4

is this really going to happen?

--
Henning Brauer, hb@..., henning@...
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

[Stuart Henderson-6]

On 2009/07/09 22:16, Henning Brauer wrote:
> * Stuart Henderson <sthen@...> [2009-07-09 21:14]:
> > Me too, but if something pulls in 2.3 as a BUILD or LIB depend, and
> > something else pulls in 2.4
>
> is this really going to happen?

i don't know.

i can definitely foresee a time where things will start needing
2.4 client libs.

i don't know how ports in-tree at the moment behave with openldap
2.4, next time i get hold of a machine i can sensibly run a bulk
build on, i'll give that a go.

if everything works with 2.4, maybe we could install 2.4 into the
normal place and move 2.3 libs and headers to a non-standard location
or something so other ports don't pick them up...

[Toni Mueller-7]

Hi,

On Thu, 09.07.2009 at 22:16:58 +0200, Henning Brauer <lists-openbsdports@...> wrote:
> * Stuart Henderson <sthen@...> [2009-07-09 21:14]:
> > Me too, but if something pulls in 2.3 as a BUILD or LIB depend, and
> > something else pulls in 2.4
>
> is this really going to happen?

I don't know either, but bad memories about the qmail-ldap and
pure-ftpd problems, caused by OpenLDAP's API changes, creep back into
my mind. It's not entirely out of the question that they did it again,
maybe on a bigger scale, when they went from 2.3 to 2.4. Therefore, I
don't expect an upgrade to 2.4 being a drop-in replacement, even if the
database was already in [bh]db format.


--
Kind regards,
--Toni++

[Henning Brauer-8]

* Stuart Henderson <sthen@...> [2009-07-10 02:12]:

> On 2009/07/09 22:16, Henning Brauer wrote:
> > * Stuart Henderson <sthen@...> [2009-07-09 21:14]:
> > > Me too, but if something pulls in 2.3 as a BUILD or LIB depend, and
> > > something else pulls in 2.4
> >
> > is this really going to happen?
>
> i don't know.
>
> i can definitely foresee a time where things will start needing
> 2.4 client libs.

can't these depend on openldap-2.4 and everything else on openldap-*
then?

don't get me wrong, I really can't judge.
I just don't wanna see overdesigned complexity to solve a non-issue.

--
Henning Brauer, hb@..., henning@...
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

[Stuart Henderson-6]

On 2009/07/10 12:34, Henning Brauer wrote:

> * Stuart Henderson <sthen@...> [2009-07-10 02:12]:
> > On 2009/07/09 22:16, Henning Brauer wrote:
> > > * Stuart Henderson <sthen@...> [2009-07-09 21:14]:
> > > > Me too, but if something pulls in 2.3 as a BUILD or LIB depend, and
> > > > something else pulls in 2.4
> > >
> > > is this really going to happen?
> >
> > i don't know.
> >
> > i can definitely foresee a time where things will start needing
> > 2.4 client libs.
>
> can't these depend on openldap-2.4 and everything else on openldap-*
> then?

the packages would have to be built against the right libraries...
hmmm... just noticed that libldap-2.3.so.* is installed and also a
symlink libldap-so.*. I wonder how much would break if we remove
the symlink.

that's another thing to try when I can get a bulk build machine
together then.

[Vijay Sankar]

Stuart Henderson wrote:

> On 2009/07/10 12:34, Henning Brauer wrote:
>  
>> * Stuart Henderson <sthen@...> [2009-07-10 02:12]:
>>    
>>> On 2009/07/09 22:16, Henning Brauer wrote:
>>>      
>>>> * Stuart Henderson <sthen@...> [2009-07-09 21:14]:
>>>>        
>>>>> Me too, but if something pulls in 2.3 as a BUILD or LIB depend, and
>>>>> something else pulls in 2.4
>>>>>          
>>>> is this really going to happen?
>>>>        
>>> i don't know.
>>>
>>> i can definitely foresee a time where things will start needing
>>> 2.4 client libs.
>>>      
>> can't these depend on openldap-2.4 and everything else on openldap-*
>> then?
>>    
>
> the packages would have to be built against the right libraries...
> hmmm... just noticed that libldap-2.3.so.* is installed and also a
> symlink libldap-so.*. I wonder how much would break if we remove
> the symlink.
>
> that's another thing to try when I can get a bulk build machine
> together then.
>
>  

I have a server with a lot of diskspace, 12GB RAM (only 3.2GB is being
used), and is currently running AMD64 4.5 -stable. I have a spare set of
drives (eight 450GB drives) that I can use to install -current and do a
bulk build.  Will that be of any help or do you need the server at your
location?

server2$ df -h
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/sd0a     15.7G   67.3M   14.9G     0%    /
/dev/sd1a      504G    2.0K    479G     0%    /corp
/dev/sd0h      243G    120G    111G    52%    /home
/dev/sd1f      136G    2.0K    130G     0%    /private
/dev/sd1b      504G    2.0K    479G     0%    /src
/dev/sd1d      504G    2.0K    479G     0%    /storage
/dev/sd0g     15.7G    6.0K   15.0G     0%    /tmp
/dev/sd0d     63.0G   12.6G   47.2G    21%    /usr
/dev/sd0e     31.5G   14.6M   29.9G     0%    /var
/dev/sd0f     31.5G   39.9M   29.9G     0%    /var/www


hw.machine=amd64
hw.model=Intel(R) Xeon(R) CPU E5405 @ 2.00GHz
hw.ncpu=4
hw.byteorder=1234
hw.pagesize=4096
hw.disknames=sd0,sd1,cd0
hw.diskcount=3
hw.sensors.cpu0.temp0=36.00 degC
hw.sensors.cpu1.temp0=36.00 degC
hw.sensors.cpu2.temp0=36.00 degC
hw.sensors.cpu3.temp0=36.00 degC
hw.sensors.mfi0.drive0=online (sd0), OK
hw.sensors.mfi0.drive1=online (sd1), OK
hw.cpuspeed=1995
hw.vendor=Dell Inc.
hw.product=PowerEdge 2900
hw.serialno=G6GH1J1
hw.uuid=44454c4c-3600-1047-8048-c7c04f314a31
hw.physmem=3483697152
hw.usermem=3483488256


--
Vijay Sankar, M.Eng., P.Eng.
ForeTell Technologies Limited
59 Flamingo Avenue, Winnipeg, MB, Canada R3J 0X6
Phone: [phone], E-Mail: vsankar@...

[Stuart Henderson-6]

On 2009/07/10 06:11, Vijay Sankar wrote:
> Stuart Henderson wrote:
> >that's another thing to try when I can get a bulk build machine
> >together then.

> I have a server with a lot of diskspace, 12GB RAM (only 3.2GB is
> being used), and is currently running AMD64 4.5 -stable. I have a
> spare set of drives (eight 450GB drives) that I can use to install
> -current and do a bulk build.  Will that be of any help or do you
> need the server at your location?

thanks Vijay and Rod for the kind offers, sorry I should have
made myself clearer though, that was a "Stuart finding time to
gather various bits in scattered machines in ~/Attic and put
them into one machine" problem rather than an actual lack of
said bits ;-)

(things like already having a full set of distfiles make it
a lot more convenient to work on my own lan).