Re: Effort to remove libdb

2020-01-20 Thread Stephen John Smoogen
On Mon, 20 Jan 2020 at 03:59, Panu Matilainen wrote: > > On 1/17/20 3:03 PM, Stephen John Smoogen wrote: > > On Fri, 17 Jan 2020 at 01:16, Chris Adams wrote: > >> > >> Once upon a time, Nico Kadel-Garcia said: > >>> Is there any software or service that currently uses Berkeley DB that > >>> cann

Re: Effort to remove libdb

2020-01-20 Thread Panu Matilainen
On 1/17/20 3:03 PM, Stephen John Smoogen wrote: On Fri, 17 Jan 2020 at 01:16, Chris Adams wrote: Once upon a time, Nico Kadel-Garcia said: Is there any software or service that currently uses Berkeley DB that cannot reasonably be discarded and rebuilt from scratch for new versions of that so

Re: Effort to remove libdb

2020-01-17 Thread Stephen John Smoogen
On Fri, 17 Jan 2020 at 01:16, Chris Adams wrote: > > Once upon a time, Nico Kadel-Garcia said: > > Is there any software or service that currently uses Berkeley DB that > > cannot reasonably be discarded and rebuilt from scratch for new > > versions of that software, without Berkeley DB entirely,

Re: Effort to remove libdb

2020-01-17 Thread Nicolas Mailhot via devel
Le jeudi 16 janvier 2020 à 20:52 -0700, Jerry James a écrit : > On Thu, Jan 16, 2020 at 8:29 PM Nico Kadel-Garcia > wrote: > > The lack of a good backup tool for Berkeley DB earned me nearly a > > year > > of contracting salary from the BBC to keep alive an obsolete > > Berkeley > > DB and Apache

Re: Effort to remove libdb

2020-01-17 Thread Guido Aulisi
Ah, it permits linking only with GPLv3!!! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ Li

Re: Effort to remove libdb

2020-01-17 Thread Guido Aulisi
Sorry if I misunderstood, but I thought BDB was licensed under the GNU AFFERO GENERAL PUBLIC LICENSE v3 [1]. Is that not correct? Ciao Guido [1]: https://www.oracle.com/downloads/licenses/berkeleydb-oslicense.html ___ devel mailing list -- devel@lists.f

Re: Effort to remove libdb

2020-01-17 Thread Stephen J. Turnbull
Nico Kadel-Garcia writes: > On Thu, Jan 16, 2020 at 10:53 PM Jerry James wrote: > > > > On Thu, Jan 16, 2020 at 8:29 PM Nico Kadel-Garcia wrote: > > > The lack of a good backup tool for Berkeley DB earned me nearly a year > > > of contracting salary from the BBC to keep alive an obsolete Ber

Re: Effort to remove libdb

2020-01-17 Thread Petr Pisar
On Fri, Jan 17, 2020 at 12:29:54AM -0500, Nico Kadel-Garcia wrote: > Is there any software or service that currently uses Berkeley DB that > cannot reasonably be discarded and rebuilt from scratch for new > versions of that software, without Berkeley DB entirely, as part of a > Fedora release? E.g

Re: Effort to remove libdb

2020-01-16 Thread Chris Adams
Once upon a time, Nico Kadel-Garcia said: > Is there any software or service that currently uses Berkeley DB that > cannot reasonably be discarded and rebuilt from scratch for new > versions of that software, without Berkeley DB entirely, as part of a > Fedora release? One problem is the upgrade

Re: Effort to remove libdb

2020-01-16 Thread Nico Kadel-Garcia
On Thu, Jan 16, 2020 at 10:53 PM Jerry James wrote: > > On Thu, Jan 16, 2020 at 8:29 PM Nico Kadel-Garcia wrote: > > The lack of a good backup tool for Berkeley DB earned me nearly a year > > of contracting salary from the BBC to keep alive an obsolete Berkeley > > DB and Apache 1.3 on RHEL syst

Re: Effort to remove libdb

2020-01-16 Thread Jerry James
On Thu, Jan 16, 2020 at 8:29 PM Nico Kadel-Garcia wrote: > The lack of a good backup tool for Berkeley DB earned me nearly a year > of contracting salary from the BBC to keep alive an obsolete Berkeley > DB and Apache 1.3 on RHEL systems long after httpd 2.x was released. > It was discarded by Su

Re: Effort to remove libdb

2020-01-16 Thread Nico Kadel-Garcia
On Thu, Jan 16, 2020 at 1:17 PM Jerry James wrote: > > On Thu, Jan 16, 2020 at 9:09 AM Filip Janus wrote: > > Hi all, > > as you maybe know the BerkeleyDB 6.x has a more restrictive license than > > the previous versions (AGPLv3 vs. LGPLv2), and due to that many projects > > cannot use it. > >

Re: Effort to remove libdb

2020-01-16 Thread Simo Sorce
Would it be possible to have a libdb-compat package with the 5.x version to at least decouple the packages that are somewhat stuck with that version of libdb and the ones that can use newer version? I still need to figure out how sasl can switch databases, the problem is that I do not want to tras

Re: Effort to remove libdb

2020-01-16 Thread Stephen John Smoogen
On Thu, 16 Jan 2020 at 15:42, Stephen John Smoogen wrote: > > On Thu, 16 Jan 2020 at 14:57, Mark Reynolds wrote: > > > > > > On 1/16/20 2:38 PM, Stephen John Smoogen wrote: > > > On Thu, 16 Jan 2020 at 14:35, Mark Reynolds wrote: > > >> 389 Directory Server (389-ds-base), aka Red Hat Directory S

Re: Effort to remove libdb

2020-01-16 Thread Mark Reynolds
On 1/16/20 3:42 PM, Stephen John Smoogen wrote: On Thu, 16 Jan 2020 at 14:57, Mark Reynolds wrote: On 1/16/20 2:38 PM, Stephen John Smoogen wrote: On Thu, 16 Jan 2020 at 14:35, Mark Reynolds wrote: 389 Directory Server (389-ds-base), aka Red Hat Directory Server, is dependent on libdb. W

Re: Effort to remove libdb

2020-01-16 Thread Stephen John Smoogen
On Thu, 16 Jan 2020 at 14:57, Mark Reynolds wrote: > > > On 1/16/20 2:38 PM, Stephen John Smoogen wrote: > > On Thu, 16 Jan 2020 at 14:35, Mark Reynolds wrote: > >> 389 Directory Server (389-ds-base), aka Red Hat Directory Server, is > >> dependent on libdb. We are currently working towards mov

Re: Effort to remove libdb

2020-01-16 Thread Mark Reynolds
On 1/16/20 2:38 PM, Stephen John Smoogen wrote: On Thu, 16 Jan 2020 at 14:35, Mark Reynolds wrote: 389 Directory Server (389-ds-base), aka Red Hat Directory Server, is dependent on libdb. We are currently working towards moving to LMDB, but that work is probably a year away from being fully

Re: Effort to remove libdb

2020-01-16 Thread Stephen John Smoogen
On Thu, 16 Jan 2020 at 14:35, Mark Reynolds wrote: > > 389 Directory Server (389-ds-base), aka Red Hat Directory Server, is > dependent on libdb. We are currently working towards moving to LMDB, but > that work is probably a year away from being fully complete. We are > hoping/planning to hav

Re: Effort to remove libdb

2020-01-16 Thread Mark Reynolds
389 Directory Server (389-ds-base), aka Red Hat Directory Server, is dependent on libdb.  We are currently working towards moving to LMDB, but that work is probably a year away from being fully complete.  We are hoping/planning to have it done for the next major release of RHEL.  I would hope l

Re: Effort to remove libdb

2020-01-16 Thread Jerry James
On Thu, Jan 16, 2020 at 9:09 AM Filip Janus wrote: > Hi all, > as you maybe know the BerkeleyDB 6.x has a more restrictive license than the > previous versions (AGPLv3 vs. LGPLv2), and due to that many projects cannot > use it. > Few years ago there was an effort to reduce the number of dependen

Re: Effort to remove libdb

2020-01-16 Thread Neal Gompa
On Thu, Jan 16, 2020 at 11:09 AM Filip Janus wrote: > > Hi all, > as you maybe know the BerkeleyDB 6.x has a more restrictive license than the > previous versions (AGPLv3 vs. LGPLv2), and due to that many projects cannot > use it. > Few years ago there was an effort to reduce the number of depen

Effort to remove libdb

2020-01-16 Thread Filip Janus
Hi all, as you maybe know the BerkeleyDB 6.x has a more restrictive license than the previous versions (AGPLv3 vs. LGPLv2), and due to that many projects cannot use it. Few years ago there was an effort to reduce the number of dependent packages on BerkeleyDB(libdb). And nowadays situation seems to