Fedora Looking To Transition The RPM Database From Berkeley DB To SQLite

[Anvil]

doesn't really answer the q why would they go for a relational db. "cos everyone's doing that" sort of thing?

might be better off to Ask the RPM Devs on the Mailing List or in freenode #rpm.org irc channel https://rpm.org/community.html

[bug77]

That's correct. The problem with the Berkeley DB license change (from GPL to AGPL) is that it was driven by Oracle as a way to generate more revenue after the acquisition but it introduces licensing incompatibility for the users like RPM. RPM is under GPLv2 and this is AGPLv3 incompatible. To comply with the license, one would have to relicense RPM as well as its dependencies to be AGPLv3 or later. Red Hat doesn't use any copyright license agreement with RPM and RPM has hundreds of contributors and a long history. It would be a huge undertaking to do this. It is just much easier to switch the database backend instead

Thank you, sir. Helpful as always.

[jabl]

doesn't really answer the q why would they go for a relational db. "cos everyone's doing that" sort of thing?

sqlite is a good choice for an embedded key-value store with ACID properties even if you don't use the full power of SQL.

[grigi]

And here I thought the real problem with BDB was how fragile it was, I stopped using it ~12 years ago due to better solutions (sqlite/leveldb)

[mos87]

sqlite is a good choice for an embedded key-value store with ACID properties even if you don't use the full power of SQL.

suppose so.
but there are actual stable and modern key-value engines, why go for something so 'catch all' for something so basic and stable as your system's very backbone...

[RahulSundaram]

suppose so.
but there are actual stable and modern key-value engines, why go for something so 'catch all' for something so basic and stable as your system's very backbone...

That seems to imply Sqlite is not stable or modern. In reality Sqlite is extremely robust and used pretty much everywhere, iOS for storing text messages, Firefox config store, FreeBSD for its package management system and heck, Solaris even uses it for basic bootup via SMF

[mos87]

That seems to imply Sqlite is not stable or modern. In reality Sqlite is extremely robust and used pretty much everywhere, iOS for storing text messages, Firefox config store, FreeBSD for its package management system and heck, Solaris even uses it for basic bootup via SMF

I never intended to imply that.

I'm surprised that FreeBSD and Solaris use it for system stuff.

The point tho still stands - why go relational for this?? The answer that this embedded sql-compatible engine make for a good key-value store doesn't satisfy my curiosity. There are modern and capable BDB alternatives - that what was actually implied. So it must be more than license for sure..

PS firefox ios et al cases are not surprising tho. I know FF uses it - but so it does a lot of other weird stuff. All web things do for that matter.

[bug77]

I never intended to imply that.

I'm surprised that FreeBSD and Solaris use it for system stuff.

The point tho still stands - why go relational for this?? The answer that this embedded sql-compatible engine make for a good key-value store doesn't satisfy my curiosity. There are modern and capable BDB alternatives - that what was actually implied. So it must be more than license for sure..

PS firefox ios et al cases are not surprising tho. I know FF uses it - but so it does a lot of other weird stuff. All web things do for that matter.

Sqlite helps when your configuration becomes a little to complicated to handle with a .properties or .yaml file. When you get to that point, being able to do a "select" helps a great deal, even if the relational nature of the solution may not be used at all.

Sqlite is the most deployed DB engine on the planet (a lot of applications manage their settings and other internal data using Sqlite), so if it works for all those people, it can't be the poorest choice for rpm, can it?

[Michael_S]

The general beef with AGPLv3 for something like BDB is the claim that it discriminates against a category of user (those that want to use the software/library in their non-open solution), as the linking exception does not apply (in simple terms, you can't link to (later versions of) BDB without open sourcing everything). AGPLv3 is typically used to ensure that only the developer themselves can decide how to monetize any use of their work (typically by providing a dual-use license for those that do not want to open source all their software), although even AGPLv3 has a cloud service loophole which the SSPL was intended to address (to ensure, again, that the developer could determine monetization). Whether every piece of software *should* be open source is an interesting discussion, but *requiring* all software to be open source is considered a step too far by many (at least Debian and RedHat) as it eliminates freedoms.

Many projects under the AGPL don't have a Contributor License Agreement (CLA). For those projects, as soon as a single person outside the core group contributes a line of code they accept, nobody can monetize it through proprietary licensing.

Sure, many companies like Oracle use AGPL or even just the GPL plus a CLA to make sure they have a monopoly on proprietary forks of a project. But your use of 'typically' is unfair. The FSF didn't create the AGPL with proprietary forks in mind, and hundreds of projects that adopt the AGPL don't use it with proprietary forks in mind either.

I suppose you would argue that Cuisinart manufactures knives typically for sale to murderers, too.

[RahulSundaram]

The point tho still stands - why go relational for this?? The answer that this embedded sql-compatible engine make for a good key-value store doesn't satisfy my curiosity. There are modern and capable BDB alternatives - that what was actually implied. So it must be more than license for sure..

What BDB alternatives did you have in mind? RPM developers have considered several db backends. You can do some quick research to satisfy your curiosity easily. Here is one example:

https://bugzilla.redhat.com/show_bug.cgi?id=1086784