HEADS UP: Berkeley DB 4...4.7 port removals/upgrades may require manual preparation

[Matthias Andree]

On 25. August 2014 07:57:36 MESZ, Scot Hetzel <swhetzel at gmail.com> wrote:
>On Sun, Aug 24, 2014 at 12:16 PM, Michael Gmelin <grembo at freebsd.org>
>wrote:
>>
>>
>> On Sun, 24 Aug 2014 11:59:37 -0500
>> Scot Hetzel <swhetzel at gmail.com> wrote:
>>
>>> On Sun, Aug 24, 2014 at 7:20 AM, Michael Gmelin <grembo at freebsd.org>
>>> wrote:
>>> > @Olli: Checking Mk/bsd.databasemk it seems like you're right. It's
>>> > quite amusing how this went unnoticed for so long, it has been in
>>> > there for eight years :)
>>> >
>>>
>>> As the original author of the USE_BDB code, the USE_BDB=5  had
>worked
>>> in the past.  As it is supposed to mean that this port only uses
>that
>>> version of BDB.  The code was changed on Aug 21 (r365599) and the
>>> author of the new code might have forgot to test this case.
>>>
>>
>> Not sure if you read the rest of the thread, but this is still
>working
>> as intended (I tested using both the old and new version).
>>
>> The issue is, that USE_BDB=version means USE_BDB=yes,
>> WITH_BDB_VER=version, but Kurt has WITH_BDB_VER=6 in make.conf,
>> which overrides this version number and version =6 is invalid for
>> devel/ice. So basically it works as designed, Kurt wanted a specific
>> version of bdb, which doesn't work for devel/ice.
>>
>> The fix was to add WANT_BDB_VER= 5 in devel/ice, which I guess is ok,
>> since this is the only version it really works with (and I guess I
>> could remove the INVALID directive now, since WANT means really
>> *want*).
>>
>
>Hmm, I thought I had it implemented this way at one time.  Any way.
>What we should be doing with the WITH_BDB_VER is not overriding the
>USE_BDB value.  Instead we should see if it is a VALID version to use
>for this port, if it is not, then use the USE_BDB value.
>
>So basically the code should be doing the following:
>
>USE_BDB=yes
> - use the default version (48+) or the installed version if higher
>
>USE_BDB=yes, WITH_BDB_VER=6
> - use version 6
>
>USE_BDB=5
> - should mean the same as USE_BDB=yes, WANT_BDB_VER=5
> - shouldn't be able to override by setting WITH_BDB_VER=6
> - this would also allow the removal of the WANT_BDB_VER variable.
>- no error should be generated when WITH_BDB_VER is set to an invalid
>version
>
>USE_BDB=48 6
> - use (either 48 or 6) or the installed version that matches one of
>these versions
>- no error should be generated when WITH_BDB_VER is set to an invalid
>version
>
>USE_BDB=5+, WITH_BDB_VER=48
> - use version 5+ or the installed version if higher
> - shouldn't allow downgrade to a lower unsupported version by setting
>the WITH_BDB_VER
> -- should we still display an error in this case or just install the
>port with bdb 5+?
>
>If we make the above changes to the code, then INVALID_BDB_VER and
>WANT_BDB_VER could disappear.
>
>> My question is, what the point of INVALID_BDB_VER really is in this
>> case, it seems a bit pointless to me given the trouble it caused Kurt
>> and how we resolved this. Having a fully specified list of supported
>> versions in WANT_BDB_VER seems better in this case (assuming WANT
>> supports listing multiple versions).
>>
>
>At the time I had implemented the code, INVALID_BDB_VER was meant to
>poke holes in the VER+:
>
>USE_BDB=2+
>INVALID_BDB_VER=3
>
>So the port would be able to use version 2 and 40+, and not 3.
>Probably should have just implanted it as:
>
>USE_BDB=2 40+
>
> and skipped the INVALID_BDB_VER entirely.
>
>I was also thinking that we should make WITH_BDB_HIGHEST the default.
>It is used by VER+ when multiple versions of bdb are installed.   That
>way we can remove this variable also.
>
>-- 
>DISCLAIMER:
>
>No electrons were maimed while sending this message. Only slightly
>bruised.
>_______________________________________________
>freebsd-ports at freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>To unsubscribe, send any mail to
>"freebsd-ports-unsubscribe at freebsd.org"

Scot,

I rewrote all of the Berkeley DB detection code to match documentation, and I will check how we can optimise the new code for corner cases.

Sorry about the inconvenience. 

Best, 
Matthias