Created attachment 216943 [details] Patch file 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 needs. 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: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=216943&action=diff#Mk/Uses/bdb.mk_sec1 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.
(In reply to Matthias Andree from comment #6) Would you please commit this bug report before databases/db6 is removed? Regarding WITH_BDB6_PERMITTED, I would like to discuss it as a separate matter.
A commit references this bug: Author: mandree Date: Wed Dec 2 00:09:16 UTC 2020 New revision: 556798 URL: https://svnweb.freebsd.org/changeset/ports/556798 Log: New port: databases/db18 Oracle Berkeley DB, Release 18.1 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 needs. This port is derived from databases/db6 (by svn copy + edits). PR: 248415 Submitted by: Yasuhiro KIMURA Changes: head/Mk/Uses/bdb.mk head/Mk/bsd.default-versions.mk head/databases/Makefile head/databases/db18/ head/databases/db18/Makefile head/databases/db18/distinfo head/databases/db18/files/patch-lang_sql_upgrade61.sh head/databases/db18/files/patch-src_dbinc_db.in head/databases/db18/pkg-descr head/databases/db18/pkg-plist
I have committed this with one additional comment near the WITH_BDB6_PERMITTED check in bdb.mk.
A commit references this bug: Author: mandree Date: Wed Dec 2 00:13:39 UTC 2020 New revision: 556799 URL: https://svnweb.freebsd.org/changeset/ports/556799 Log: databases/db18: Add file missed in commit r556798. PR: 248415 Submitted by: Yasuhiro KIMURA Changes: head/databases/db18/files/patch-dist_Makefile.in
Is there anything left undone in this pr? Can we close this one now?
I'd left this open to see if where the discussion around WITH_BDB6_PERMITTED went, per comment #5 ff. above.
^Triage: Assign to committer that resolved. Unless the relevent bdb6 option question is likely to be resolved in short order, it's probably best to track any unrelated changes in separate issues, as the issue as reported (new port), has now been resolved
(In reply to Matthias Andree from comment #12) I submitted patch to remove codes related to WITH_BDB6_PERMITTED in bug #261523. It is necessary to change default versio of BDB to 18. So please comment it instead of this one.