Version modules and data directories, and melt

[reddwarf69]

Allow the "extras" of binary incompatible versions of MLT to be installed
simultaneously.
I don't like the idea of versioning the melt binary. But kdenlive is the main
user of MLT and it expects the same formats support from both the libmltX it
is linked to, and the melt binary it uses to do the actual work.

[ddennedy]

What is the justification to add this complication and messiness? I do not want a theoretical answer. What is the real world problem you are addressing? Because, to me, this is sacrificing some simplicity for "proper management."

Also, I reject this as-is because it defaults to versioning on. This has a big impact for some things outside of Linux distributions' packages and management. The symbolic link for melt is not going to work on Windows, and I could address that, but that is kind of my point. I want the defaults to behave as they do today. Versioning needs to be opted into.

[reddwarf69]

In openSUSE 12.2 the default repository includes mlt 0.7.8 (libmlt.so.4). Packman, the repository where users find "multimedia/patents/complicated" packages provides mlt 0.8.8 (libmlt.so.5). The "devel package", multimedia:libs, also includes mlt 0.8.8, but without the avformat plugin. And I'm sure there are other home projects adding some weirdness.

The problem I found is that some users somehow always manage to mix the packages incorrectly in some way and then complain. And other users want to keep the "openSUSE original" libmlt4 while at the same time install the latest version to be able to test the latest version of openShot that was compiled somewhere in the OBS with libmlt5.

With some luck kdenlive would be the only application ever to do the weird thing of directly using libmlt for some things, but then calling melt to do the final step. So to version the binary shouldn't be necessary (I guess I can fix the problem adding some manual provides to the RPM packages).
But versioning the modules/data directories would be nice. I didn't really look at the code of kdenlive so much, but ideally the modules/data directories should be abstracted so only libmlt itself would care. Why is that information leaked to kdenlive?

[ddennedy]

Thank you; I now have a greater appreciation of the problem. I think Debian users may be in the same boat when using Debian and debian-multimedia.org. Or, Ubuntu users using PPAs. I am willing to accept the increased complexity; I suppose it is not that bad.

Kdenlive does not directly access the data directories. Perhaps something I wrote was not interpreted as I intended. :-) It is not so unusual that Kdenlive uses melt to do the rendering; my new project Shotcut (www.shotcut.org) does the same thing. Besides, you make a symlink for melt.

My complaint is that it requires --no-compat-dirs for the old behavior, but I would prefer instead an option to enable this new extra versioning: --enable-extra-versioning. Is that OK?

[reddwarf69]

Yes. No problem with changing it to --enable-extra-versioning.
But kdenlive asks for the "profiles" directory. That's why added the variable to the pkg-config file and patched kdenlive with https://build.opensuse.org/package/view_file?expand=1&file=kdenlive-0.9.2-mlt_datadir.patch&package=kdenlive&project=openSUSE%3AFactory.

Is this an expected use? What path information applications can reasonably expect to depend on? Those are the ones that should be in the .pc file.

[ddennedy]

Regarding kdenlive and profiles; MLT has an API for it, and Kdenlive should switch to use it, but no harm to postpone that work and leave the var in the pc file. This new commit looks nice, and thank you for accommodating my change request.