[Opendnssec-maintainers] supported sqlite3 version

[John Dickinson]

On 10 Apr 2013, at 18:17, Paul Wouters <pwouters at redhat.com> wrote:

> On 04/10/2013 08:16 AM, John Dickinson wrote:
> 
>> The OpenDNSSEC developers would like your input on the impact of changing the required version of sqlite3 in future releases of OpenDNSSEC (v1.3, v1.4 and v2). Currently the enforcer checks for at least sqlite3 >= 3.3.9 which is very old.
>> 
>> We would like to raise this requirement to sqlite3 >= 3.7.0 as this would allow us to:
>> 1. Enforce foreign key constraints. http://www.sqlite.org/foreignkeys.html
>> 2. Make use of the WAL to better handle locking issues. http://www.sqlite.org/wal.html
>> 
>> Impact of this change:
>> 
>> RHEL and derivatives ship with 3.6.20
>> Ubuntu 10.04 LTS ships with 3.6.22
>> 
>> Users of these OS's would need to install/upgrade sqlite3. Users on recent *BSD or Solaris 11 should be OK.

Thanks for the feedback Paul,

> That is a nightmare because you'd have to create an sqlite36 package or an sqlite37 package that installs in a non-default location to avoid affecting other software that cannot use 3.7 due to possible API changes. It will not be possible to ship such a version of opendnssec in EPEL-6 as we currently do.

OK - that is what I thought - I just wondered what the pain level would be.

> I would recommend waiting for RHEL and ubuntu LTS to be upgraded before demanding this switch. RHEL-7 will have sqlite 3.7.x.

You would be happy even though RHEL-6 extended support goes until 2023?

Another option is for us to have configure detect the sqlite version and only compile new features if it detects 3.7.x.

> Related, opendnssec won't be able to get into RHEL-6 properly (as opposed to being in EPEL-6) as long as it uses a non-approved/non-certified crypto library (botan). The only allowed crypto libraries are nss, openssl and libgcrypt.

Out of interest, what are the requirements needed to become approved and certified?

Thanks,
John