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
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
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,
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
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
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
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
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
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
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
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
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.
> >
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
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
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
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
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
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
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
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
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
21 matches
Mail list logo
