10:08 a.m.
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 be almost
the same. Here is
the link with packages dependent on libdb[1] from previous effort, which is
truthful for nowadays situation. As a member of the database team which is
responsible for libdb, I would like to know your opinions on this problem,
because many components have many specific cases where is libdb used.
Nowadays we would like to remove libdb from Fedora as soon as possible, in
the best case from Fedora 33. But I am afraid, that it isn't real.
I have discussed this issue with my colleagues and we propose an approach.
We found that the biggest problem would occur in updating components from
versions that support libdb to versions without this support. Here could
arise problems of inconsistency.
Our approach assumes to convert old libdb databases to other supported
database format in each package related to this libdb issue. Result would
be Fedora without libdb.
I know that this approach probably isn't perfect.
Therefore I would like to ask for Your opinions, suggestions and every
problem clarification.
Thank you very much for any help. I welcome every opinion.
[1]
https://fedoraproject.org/w/index.php?title=User:Pkubat/Draft_-_Removing_...
Fiip Januš - Red Hat Associate Developer Engineer - Databases Team
11:49 a.m.
On Thu, Jan 16, 2020 at 11:09 AM Filip Janus <fjanus(a)redhat.com> 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 dependent packages on
BerkeleyDB(libdb). And nowadays situation seems to be almost the same. Here is
the link with packages dependent on libdb[1] from previous effort, which is truthful for
nowadays situation. As a member of the database team which is responsible for libdb, I
would like to know your opinions on this problem, because many components have many
specific cases where is libdb used.
Nowadays we would like to remove libdb from Fedora as soon as possible, in the best case
from Fedora 33. But I am afraid, that it isn't real.
I have discussed this issue with my colleagues and we propose an approach. We found that
the biggest problem would occur in updating components from versions that support libdb to
versions without this support. Here could arise problems of inconsistency.
Our approach assumes to convert old libdb databases to other supported database format in
each package related to this libdb issue. Result would be Fedora without libdb.
I know that this approach probably isn't perfect.
Therefore I would like to ask for Your opinions, suggestions and every problem
clarification.
Thank you very much for any help. I welcome every opinion.
[1]
https://fedoraproject.org/w/index.php?title=User:Pkubat/Draft_-_Removing_...
I'm very much in support of a plan for this. In my opinion, the sooner
the better.
At least for RPM, I have personally been testing the non-BDB backends
since they were introduced in various environments. I'm currently
using the NDB backend for a couple of projects (POSIX stack for
Windows, and a devtool stack for macOS), and have been testing the
SQLite backend in rpm git master since it was introduced a few months
ago in a Linux distribution.
Also in the RPM case, support recently landed for reading BDB rpmdb
without libdb for supporting inspecting and converting from a BDB
rpmdb. So it's technically possible to do a conversion from bdb to
something else without libdb being linked to it.
--
真実はいつも一つ！/ Always, there's only one truth!
12:16 p.m.
On Thu, Jan 16, 2020 at 9:09 AM Filip Janus <fjanus(a)redhat.com> 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 dependent packages on
BerkeleyDB(libdb). And nowadays situation seems to be almost the same. Here is
the link with packages dependent on libdb[1] from previous effort, which is truthful for
nowadays situation. As a member of the database team which is responsible for libdb, I
would like to know your opinions on this problem, because many components have many
specific cases where is libdb used.
Nowadays we would like to remove libdb from Fedora as soon as possible, in the best case
from Fedora 33. But I am afraid, that it isn't real.
I have discussed this issue with my colleagues and we propose an approach. We found that
the biggest problem would occur in updating components from versions that support libdb to
versions without this support. Here could arise problems of inconsistency.
Our approach assumes to convert old libdb databases to other supported database format in
each package related to this libdb issue. Result would be Fedora without libdb.
I know that this approach probably isn't perfect.
Therefore I would like to ask for Your opinions, suggestions and every problem
clarification.
Thank you very much for any help. I welcome every opinion.
For the xemacs package, I can simply build with gdbm instead of libdb.
The question is how to migrate XEmacs users' existing databases. Is
there a tool to, say, convert the libdb dump format to the gdbm dump
format, or otherwise convert the database? We don't necessarily need
to run such a tool ourselves, so long as we note the need to run it in
Fedora's release notes.
Database support is optional in XEmacs, and is not used for anything
terribly important, so if we have to just switch to gdbm and tell the
users, "Sorry, your databases have to be recreated from scratch," it
probably won't be the end of the world, but it would be nice if we
could offer some kind of migration path.
--
Jerry James
http://www.jamezone.org/
9:28 p.m.
On Thu, Jan 16, 2020 at 1:17 PM Jerry James <loganjerry(a)gmail.com> wrote:
On Thu, Jan 16, 2020 at 9:09 AM Filip Janus <fjanus(a)redhat.com> 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 dependent packages on
BerkeleyDB(libdb). And nowadays situation seems to be almost the same. Here is
> the link with packages dependent on libdb[1] from previous effort, which is truthful
for nowadays situation. As a member of the database team which is responsible for libdb, I
would like to know your opinions on this problem, because many components have many
specific cases where is libdb used.
>
> Nowadays we would like to remove libdb from Fedora as soon as possible, in the best
case from Fedora 33. But I am afraid, that it isn't real.
>
> I have discussed this issue with my colleagues and we propose an approach. We found
that the biggest problem would occur in updating components from versions that support
libdb to versions without this support. Here could arise problems of inconsistency.
>
> Our approach assumes to convert old libdb databases to other supported database
format in each package related to this libdb issue. Result would be Fedora without libdb.
> I know that this approach probably isn't perfect.
>
> Therefore I would like to ask for Your opinions, suggestions and every problem
clarification.
> Thank you very much for any help. I welcome every opinion.
For the xemacs package, I can simply build with gdbm instead of libdb.
The question is how to migrate XEmacs users' existing databases. Is
there a tool to, say, convert the libdb dump format to the gdbm dump
format, or otherwise convert the database? We don't necessarily need
to run such a tool ourselves, so long as we note the need to run it in
Fedora's release notes.
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 Subversion with good cause.
Why does XEmacs need to preserve a database?
Database support is optional in XEmacs, and is not used for anything
terribly important, so if we have to just switch to gdbm and tell the
users, "Sorry, your databases have to be recreated from scratch," it
probably won't be the end of the world, but it would be nice if we
could offer some kind of migration path.
Is there anything that couldn't expect a rebuild as part an OS
release? Anything that people actually use, besides XEmacs?
9:52 p.m.
On Thu, Jan 16, 2020 at 8:29 PM Nico Kadel-Garcia <nkadel(a)gmail.com> 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 Subversion with good cause.
Why does XEmacs need to preserve a database?
It may not. XEmacs provides a generic "database" interface in Emacs
Lisp. The underlying database can be libdb, gdbm, ndbm, and probably
something else I've forgotten. XEmacs itself only uses that interface
to keep a Unicode code point database. That is easily recreated.
The problem is that I have no way of knowing what people have done
with the Lisp interface, what databases they may have created. It is
entirely possible that 0 people will be impacted if I change the
builds to use gdbm instead. It is also possible that I will get lots
of bugs filed by angry people who can't access their databases
anymore. I have no way to tell (without actually doing it and seeing
how many bugs get filed, of course).
Is there anything that couldn't expect a rebuild as part an OS
release? Anything that people actually use, besides XEmacs?
Sorry, I'm not catching your meaning here.
--
Jerry James
http://www.jamezone.org/
11:29 p.m.
On Thu, Jan 16, 2020 at 10:53 PM Jerry James <loganjerry(a)gmail.com> wrote:
On Thu, Jan 16, 2020 at 8:29 PM Nico Kadel-Garcia <nkadel(a)gmail.com> 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 Subversion with good cause.
>
> Why does XEmacs need to preserve a database?
It may not. XEmacs provides a generic "database" interface in Emacs
Lisp. The underlying database can be libdb, gdbm, ndbm, and probably
something else I've forgotten. XEmacs itself only uses that interface
to keep a Unicode code point database. That is easily recreated.
The problem is that I have no way of knowing what people have done
with the Lisp interface, what databases they may have created. It is
entirely possible that 0 people will be impacted if I change the
builds to use gdbm instead. It is also possible that I will get lots
of bugs filed by angry people who can't access their databases
anymore. I have no way to tell (without actually doing it and seeing
how many bugs get filed, of course).
> Is there anything that couldn't expect a rebuild as part an OS
> release? Anything that people actually use, besides XEmacs?
Sorry, I'm not catching your meaning here.
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? Subversion used to provide it for compatibility, but
it's been so long I think we could reasonable leave Berkeley DB
entirely out of it.
12:15 a.m.
Once upon a time, Nico Kadel-Garcia <nkadel(a)gmail.com> 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 path - there's no way to know all the things
that are currently stored in BDB files, and once upgraded, there's not
going to be a way to get the data out. Some BDBs are built from other
data files (and can be rebuilt, although there's no way to know all the
things and trigger such rebuilds automatically), but some are directly
edited. Part of the attraction of BDB files was that they could be
easily updated from programs/scripts for use by other programs/scripts.
postfix and sendmail both use BDB files for maps. IIRC sendmail just
supports a single map database library at a time, configured at build
time (can be GDBM or BDB). postfix supports some alternates, but BDB is
considered the standard (and changing to anything else requires
modifying configuration before rebuilding maps). I think exim is
similar (I'm just not as familiar with it).
Not all things that use BDB even support alternates (or dump and restore
of data files), for example arpd from iproute. Also, since the
scripting languages (python/php/perl) have supported it as a
service-free simple DB, there's going to be an unknown number of scripts
that use it that aren't packaged as part of the distribution.
BDB is kind of a part of the collective history of Unix systems and
assumed to always be available. Is there nobody interested in
maintaining the final license-compatible version in a pure bugfix mode?
Does it get that many bugs?
--
Chris Adams <linux(a)cmadams.net>
7:03 a.m.
On Fri, 17 Jan 2020 at 01:16, Chris Adams <linux(a)cmadams.net> wrote:
Once upon a time, Nico Kadel-Garcia <nkadel(a)gmail.com> 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?
BDB is kind of a part of the collective history of Unix systems and
assumed to always be available. Is there nobody interested in
maintaining the final license-compatible version in a pure bugfix mode?
Does it get that many bugs?
It does get some and most of them are gnarly ones where if you fix
that bug you have now introduced a whole new class of bugs for some
other set of users. There are 30 years of software which expect BDB to
work like it was when the program was originally written. You need to
be an archaeologist of knowing how BDB acted in 1994 to 2019 with all
the little tweaks and changes which have happened during that. You
also have to 'add' new features because someone is going to write some
new language or coding paradigm which needs changes.
I would expect keeping this up would require a full time company of
programmers and equipment to build all the test cases that would be
needed to try and support this.
--
Stephen J Smoogen.
2:58 a.m.
On 1/17/20 3:03 PM, Stephen John Smoogen wrote:
On Fri, 17 Jan 2020 at 01:16, Chris Adams <linux(a)cmadams.net>
wrote:
>
> Once upon a time, Nico Kadel-Garcia <nkadel(a)gmail.com> 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?
>
> BDB is kind of a part of the collective history of Unix systems and
> assumed to always be available. Is there nobody interested in
> maintaining the final license-compatible version in a pure bugfix mode?
> Does it get that many bugs?
It does get some and most of them are gnarly ones where if you fix
that bug you have now introduced a whole new class of bugs for some
other set of users. There are 30 years of software which expect BDB to
work like it was when the program was originally written. You need to
be an archaeologist of knowing how BDB acted in 1994 to 2019 with all
the little tweaks and changes which have happened during that. You
also have to 'add' new features because someone is going to write some
new language or coding paradigm which needs changes.
I would expect keeping this up would require a full time company of
programmers and equipment to build all the test cases that would be
needed to try and support this.
Yup. I guess many projects relying on BDB have been in a denial over
this. 6.5 years of waiting for "surely somebody will pick up the pieces"
hasn't changed the situation a whole lot: everybody needs it but nobody
wants it.
- Panu -
11:03 a.m.
On Mon, 20 Jan 2020 at 03:59, Panu Matilainen <pmatilai(a)redhat.com> wrote:
On 1/17/20 3:03 PM, Stephen John Smoogen wrote:
> On Fri, 17 Jan 2020 at 01:16, Chris Adams <linux(a)cmadams.net> wrote:
>>
>> Once upon a time, Nico Kadel-Garcia <nkadel(a)gmail.com> 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?
>>
>
>> BDB is kind of a part of the collective history of Unix systems and
>> assumed to always be available. Is there nobody interested in
>> maintaining the final license-compatible version in a pure bugfix mode?
>> Does it get that many bugs?
>
> It does get some and most of them are gnarly ones where if you fix
> that bug you have now introduced a whole new class of bugs for some
> other set of users. There are 30 years of software which expect BDB to
> work like it was when the program was originally written. You need to
> be an archaeologist of knowing how BDB acted in 1994 to 2019 with all
> the little tweaks and changes which have happened during that. You
> also have to 'add' new features because someone is going to write some
> new language or coding paradigm which needs changes.
>
> I would expect keeping this up would require a full time company of
> programmers and equipment to build all the test cases that would be
> needed to try and support this.
>
Yup. I guess many projects relying on BDB have been in a denial over
this. 6.5 years of waiting for "surely somebody will pick up the pieces"
hasn't changed the situation a whole lot: everybody needs it but nobody
wants it.
It also goes with the other item.. If it isn't broke (for me).. why
fix it (for others). Most people really aren't going to care about the
licenses and they probably aren't going to end up in the corner cases
which need fixing by whoever takes up the code... until some sort of
security review finds that they do..
--
Stephen J Smoogen.
2:12 a.m.
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. pam_abl collects login failures and successes from the PAM sessions to
a BDB file. There is no way of rebuildnig the database because the data source
are events in a live system. But losing the database is not a big deal as the
data are typically only helpful for a few hours.
A bigger issue is that e.g. pam_abl only supports BDB. There is no backend for
other databases. I worry there will be a lot of packages like this.
I recommend to keep the latest license-acceptible BDB in Fedora, schedule
a removal of it for a reasonably future Fedora release and file bugs
against all the packages using it that they need to migrate from BDB until
then.
This gives maintainer and upsreams enough time for migration from BDB. Then
the remaining packages will be dropped from Fedora as a regular fails to
build cleanup.
I think a similar approach was used when uprading OpenSSL to 1.1.1 version.
-- Petr
2:21 a.m.
Nico Kadel-Garcia writes:
On Thu, Jan 16, 2020 at 10:53 PM Jerry James
<loganjerry(a)gmail.com> wrote:
>
> On Thu, Jan 16, 2020 at 8:29 PM Nico Kadel-Garcia <nkadel(a)gmail.com> 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 Subversion with good cause.
> >
> > Why does XEmacs need to preserve a database?
>
> It may not. XEmacs provides a generic "database" interface in Emacs
> Lisp. The underlying database can be libdb, gdbm, ndbm, and probably
> something else I've forgotten. XEmacs itself only uses that interface
> to keep a Unicode code point database. That is easily recreated.
As Jerry points out, XEmacs doesn't. Its users do. For example, the
VM mail client can optionally use a db-style database to index mail
folders, with substantial speedup, especially on very large folders
(which the VM UI encourages). In the case of VM, this is trivially
worked around in a few seconds -- just blow away the db file, and let
VM reindex. I hope VM would respond gracefully (though with a
perceptible performance degradation but) with no loss of functionality
to removal of libdb, but it might also fatally error if it tried to
use libdb but it wasn't there, requiring manual reconfiguration to use
an alternative backend. I can't say the same for other (possible) use
cases, since it's a feature of (X)Emacs Lisp. (X)Emacs Lisp has been
used to build thousands of applications, most of which have persistent
data of some kind, and more than a few of which have persistent data
that could be kept in a libdb database.
> The problem is that I have no way of knowing what people have
done
> with the Lisp interface, what databases they may have created.
Exactly.
> It is entirely possible that 0 people will be impacted if I
> change the builds to use gdbm instead.
I think that very unlikely, since the use of a specific backend is
explicitly configured. People will notice if they've been using libdb
when support is removed.
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?
Of course you can do that as long as you're willing to raise a big
hairy middle finger to an unknown number of users. The point of a
database is persistence. Users do not expect databases to suddenly
become useless; they expect a migration path, preferably seamless and
in the background.
Regards,
Steve
2:26 a.m.
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
3:36 a.m.
Le jeudi 16 janvier 2020 à 20:52 -0700, Jerry James a écrit :
On Thu, Jan 16, 2020 at 8:29 PM Nico Kadel-Garcia
<nkadel(a)gmail.com>
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 Subversion with good cause.
>
> Why does XEmacs need to preserve a database?
It may not. XEmacs provides a generic "database" interface in Emacs
Lisp. The underlying database can be libdb, gdbm, ndbm, and probably
something else I've forgotten. XEmacs itself only uses that
interface to keep a Unicode code point database. That is easily
recreated.
Just port xemacs to Harfbuzz, fontconfig and the rest of the
freedesktop text stack. That will solve this issue and many others.
Regards,
--
Nicolas Mailhot
1:21 p.m.
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 libdb is not pulled out from underneath us before we can make
the transition to LMDB.
Mark
On 1/16/20 11:08 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 dependent
packages on BerkeleyDB(libdb). And nowadays situation seems to be
almost the same. Here is
the link with packages dependent on libdb[1] from previous effort,
which is truthful for nowadays situation. As a member of the database
team which is responsible for libdb, I would like to know your
opinions on this problem, because many components have many specific
cases where is libdb used.
Nowadays we would like to remove libdb from Fedora as soon as
possible, in the best case from Fedora 33. But I am afraid, that it
isn't real.
I have discussed this issue with my colleagues and we propose an
approach. We found that the biggest problem would occur in updating
components from versions that support libdb to versions without this
support. Here could arise problems of inconsistency.
Our approach assumes to convert old libdb databases to other supported
database format in each package related to this libdb issue. Result
would be Fedora without libdb.
I know that this approach probably isn't perfect.
Therefore I would like to ask for Your opinions, suggestions and
every problem clarification.
Thank you very much for any help. I welcome every opinion.
[1]
https://fedoraproject.org/w/index.php?title=User:Pkubat/Draft_-_Removing_...
Fiip Januš - Red Hat Associate Developer Engineer - Databases Team
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
389 Directory Server Development Team
1:38 p.m.
On Thu, 16 Jan 2020 at 14:35, Mark Reynolds <mreynolds(a)redhat.com> 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 have it done for the next major
release of RHEL. I would hope libdb is not pulled out from underneath us before we can
make the transition to LMDB.
Going from the release dates, Fedora 33 is going to be where the next
RHEL is branched.
Mark
On 1/16/20 11:08 AM, Filip Janus wrote:
--
Stephen J Smoogen.
1:57 p.m.
On 1/16/20 2:38 PM, Stephen John Smoogen wrote:
On Thu, 16 Jan 2020 at 14:35, Mark Reynolds
<mreynolds(a)redhat.com> 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 have it done for the next major
release of RHEL. I would hope libdb is not pulled out from underneath us before we can
make the transition to LMDB.
>
Going from the release dates, Fedora 33 is going to be where the next
RHEL is branched.
Isn't that for RHEL 8.4? I was referring to the next MAJOR
release of
RHEL :-) Either way, I still estimate it could still take up to a year
to get fully switched over to LMDB with our current team resources :-/
> Mark
>
> On 1/16/20 11:08 AM, Filip Janus wrote:
>
--
389 Directory Server Development Team
2:42 p.m.
On Thu, 16 Jan 2020 at 14:57, Mark Reynolds <mreynolds(a)redhat.com> wrote:
On 1/16/20 2:38 PM, Stephen John Smoogen wrote:
> On Thu, 16 Jan 2020 at 14:35, Mark Reynolds <mreynolds(a)redhat.com> 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 have it done for the next
major release of RHEL. I would hope libdb is not pulled out from underneath us before we
can make the transition to LMDB.
>>
> Going from the release dates, Fedora 33 is going to be where the next
> RHEL is branched.
Isn't that for RHEL 8.4? I was referring to the next MAJOR release of
RHEL :-) Either way, I still estimate it could still take up to a year
I sent an internal email for your enjoyment :/
to get fully switched over to LMDB with our current team resources
:-/
>
>> Mark
>>
>> On 1/16/20 11:08 AM, Filip Janus wrote:
>>
>
--
389 Directory Server Development Team
--
Stephen J Smoogen.
2:57 p.m.
On 1/16/20 3:42 PM, Stephen John Smoogen wrote:
On Thu, 16 Jan 2020 at 14:57, Mark Reynolds
<mreynolds(a)redhat.com> wrote:
>
> On 1/16/20 2:38 PM, Stephen John Smoogen wrote:
>> On Thu, 16 Jan 2020 at 14:35, Mark Reynolds <mreynolds(a)redhat.com> 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 have it done
for the next major release of RHEL. I would hope libdb is not pulled out from underneath
us before we can make the transition to LMDB.
>>>
>> Going from the release dates, Fedora 33 is going to be where the next
>> RHEL is branched.
> Isn't that for RHEL 8.4? I was referring to the next MAJOR release of
> RHEL :-) Either way, I still estimate it could still take up to a year
I sent an internal email for your enjoyment :/
Ah yes, I stand corrected on the F33
schedule, thank you for the offline
clarification! Well we will not be ready by F33, hopefully F35...
> to get fully switched over to LMDB with our current team resources :-/
>>> Mark
>>>
>>> On 1/16/20 11:08 AM, Filip Janus wrote:
>>>
> --
>
> 389 Directory Server Development Team
>
--
389 Directory Server Development Team
3:06 p.m.
On Thu, 16 Jan 2020 at 15:42, Stephen John Smoogen <smooge(a)gmail.com> wrote:
On Thu, 16 Jan 2020 at 14:57, Mark Reynolds <mreynolds(a)redhat.com> wrote:
>
>
> On 1/16/20 2:38 PM, Stephen John Smoogen wrote:
> > On Thu, 16 Jan 2020 at 14:35, Mark Reynolds <mreynolds(a)redhat.com>
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 have it done
for the next major release of RHEL. I would hope libdb is not pulled out from underneath
us before we can make the transition to LMDB.
> >>
> > Going from the release dates, Fedora 33 is going to be where the next
> > RHEL is branched.
> Isn't that for RHEL 8.4? I was referring to the next MAJOR release of
> RHEL :-) Either way, I still estimate it could still take up to a year
I sent an internal email for your enjoyment :/
And this is where i find that I was not sending email to the person
directly but the list. Thank you folks.. its been a great thirty years
but I need to go back to remedial email classes.
--
Stephen J Smoogen.
3:45 p.m.
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 trash users setup by invalidating their
saslauthdb databases, at the same time I see no easy way to migrate
them as those db could be anywhere on the system.
However I could potential try and ondemand upgrade if libdb were still
available (via libdb-compat) for releases (to catch upgrades that skip
a release) so that the database could be read and then rewritten back
in the new format at first use.
Note I do not know if even this plan is feasible, but wanted to know if
I should even try to feigure out or if libdb-compat is an
impossibility.
Simo.
On Thu, 2020-01-16 at 17:08 +0100, 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 dependent
packages on BerkeleyDB(libdb). And nowadays situation seems to be almost
the same. Here is
the link with packages dependent on libdb[1] from previous effort, which is
truthful for nowadays situation. As a member of the database team which is
responsible for libdb, I would like to know your opinions on this problem,
because many components have many specific cases where is libdb used.
Nowadays we would like to remove libdb from Fedora as soon as possible, in
the best case from Fedora 33. But I am afraid, that it isn't real.
I have discussed this issue with my colleagues and we propose an approach.
We found that the biggest problem would occur in updating components from
versions that support libdb to versions without this support. Here could
arise problems of inconsistency.
Our approach assumes to convert old libdb databases to other supported
database format in each package related to this libdb issue. Result would
be Fedora without libdb.
I know that this approach probably isn't perfect.
Therefore I would like to ask for Your opinions, suggestions and every
problem clarification.
Thank you very much for any help. I welcome every opinion.
[1]
https://fedoraproject.org/w/index.php?title=User:Pkubat/Draft_-_Removing_...
Fiip Januš - Red Hat Associate Developer Engineer - Databases Team
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
1551
days inactive
1555
days old
21 comments
13 participants
participants (13)
-
Chris Adams -
Filip Janus -
Guido Aulisi -
Jerry James -
Mark Reynolds -
Neal Gompa -
Nico Kadel-Garcia -
Nicolas Mailhot -
Panu Matilainen -
Petr Pisar -
Simo Sorce -
Stephen J. Turnbull -
Stephen John Smoogen