Created attachment 216943 [details]
Oracle Berkeley DB is a family of open source embeddable databases
that allows developers to incorporate within their applications a
fast, scalable, transactional database engine with industrial grade
reliability and availability. As a result, customers and end-users
will experience an application that simply works, reliably manages
data, can scale under extreme load, but requires no ongoing database
administration. As a developer, you can focus on your application and
be confident that Oracle Berkeley DB will manage your persistence
To apply attached patch please take following steps.
1. cd /usr/ports
2. svn copy databases/db6 databases/db18
3. svn patch /path/to/attached/patch
Is it possible to replace db6 with db18?
(In reply to VVD from comment #1)
It's a bit difficult to answer. What I can say is
* Neither format of database file nor log file is changed between 6.2 and 18.1.
* Berkeley DB has been developed so it keeps backward compatibility of API. So source code that can be compiled with 6.2 should also be compiled with 18.1
* However, sometimes problem happens beyond scope of API compatibility. One of such cases is databases/ruby-bdb port. Because it it Ruby port it uses extconf.rb as configuration script. But one of them included in source archive doesn't consider case that major version of Berkeley DB has two or more digits. As a result it fails to configure with 18.1 and need to be patched. So I wouldn't be surprised even if there are another one that fails to build with 18.1 for similar reason.
testbuilds are fine
Thanks a lot.
I have not yet looked at the contribution in detail, so just a few thoughts ahead of time. I think we should go for db18 and then get rid of BDB6 as it expires. On Linux it appeared to me that bogofilter self-tests also passed against Oracle Berkeley DB 18.
One thing I can say already is that we should re-investigate this part in bdb.mk:
I introduced WITH_BDB6_PERMITTED at the time due to the more restrictive licensing (AGPL vs. SleepyCat license with the switch from db5 to db6) to avoid surprising people who run their BDB-based product as a service.
I now propose to *add* a new alternative WITH_BDB_AGPL_PERMITTED as an alternative because after removal of db6, with just db5 and db18 in the ports tree, nobody will be able to understand any more what the purpose of WITH_BDB6_PERMITTED used to be. WITH_BDB6_PERMITTED should then also emit warnings such that users migrate to WITH_BDB_AGPL_PERMITTED and after a year or so we should remove the WITH_BDB6* stuff.
I think the AGPL also requires us to mirror the distfiles while we distribute binary packages.
(In reply to Matthias Andree from comment #4)
Regarding WITH_BDB6_PERMITTED, I prefer simply removing it. If someone doesn't want to use AGPLv3 software, then he can refuse it by adding 'LICENSES_REJECTED=AGPLv3 AGPLv3+' in /etc/make.conf. I'm not sure if there is someone who accepts AGPLv3 itself but don't wan't to use AGPLv3-licensed Berkeley DB. But if there really is then he can achieve it by adding 'DEFAULT_VERSIONS+=bdb=5' in /etc/make.conf. Ports framework can handle license issue systematically. So it's better to use it rather than handling license issue in individual port.
(In reply to Yasuhiro KIMURA from comment #5)
The original purpose of this option was to auto-select a db version with compatible license, I don't think that LICENSES_REJECTED=AGPLv3 will do the trick; if we document the DEFAULT_VERSIONS idea however, then it might work.
I am not sure if we should do an exp-run just to stay on the safe side - perhaps we should.