Kdenlive requires kf5-purpose; kf5-purpose requires kaccounts-integration; kaccounts-integration requires akonadi; akonadi requires a database. So Kdenlive requires a database. Which one is up to you, but: If you go with the package, it is MySQL.
Well, it turns out that these days, nearly every piece of software requires certain infrastructure. For example, most software uses networks, so you need good RPC support. Most software requires configuration, so they use libraries that know how to decode config files. They store data in interesting formats, which requires record management, and often databases. Given that de-facto all software needs this, wouldn't it make sense if operating systems contained the facilities as a basic part?
Well, it turns out in the 60s and 70s there was lots of research into operating systems, and a few OSes that became spectacularly successful followed that advice. For example, both System/38 and VMS shipped with a full relational database integrated into the OS, with backup facilities integrated into file systems, in the case of VMS with a networked cluster file system starting in the late 80s (VAXcluster). That was REAL progress. Alas, due to a cost-saving move by the whole industry, we ended up standardizing on the "minimum viable product" among operating systems, namely Unix (today shipped in the form of Linux and the BSDs), where none of this comfortable stuff is available by default. Interestingly, those two operating systems still exist; System/38 is still shipping today (it turned into AS/400 and then into System i, which today is just a software package you can run on a PowerPC system). And a lot of the technology from VMS (and the people that made it) ended up in Windows, through the path of NT. There is a reason that technologically, Windows has been ahead of the game in many areas, even if we (as Unix snobs) refuse to acknowledge that.
<scnr mode="curse">Using as many third party tools, libs, frameworks as possible is *modern*.
Yes, it is, And for VERY good reasons. It is insane if every developer ends up having to re-invent all the infrastructure for their little project. Using well-made existing projects is much more sensible.
Let me explain that with a little joke, from about 40 years ago (I started doing commercial data processing in the late 70s and early 80s): A small business owner wants to use computers to run his business more efficiently. And he decided that the best place to start is by automating "accounts receivable" (the act of printing invoices, collecting payments from customers, and matching payments to outstanding bills) would be the best place to start. So he buys a computer (which in those days was something big enough to require a room of its own), and hires a programmer. The programmer tells him that it will three years to develop "accounts receivable". Well, that seems expensive and slow, but the business owner has no alternative than to let the programmer do it. After one year, the business guy goes to the programmer to see what progress has been: the programmer is putting the finishing touches on an editor. He's hoping in the second year to create a compiler, and in the third an operating system. Once he has those tools, "accounts receivable" will be quick and easy.
Today, if I'm supervising a junior software engineer, or I'm doing a code review for a colleague, and I find out that they have re-implemented something that exists as a good-quality library, I will stop them, and make then use the library. Because I want them to invest their time into creating something new and useful, not re-inventing the wheel.
