munt / munt

A multi-platform software synthesiser emulating pre-GM MIDI devices such as the Roland MT-32, CM-32L, CM-64 and LAPC-I. In no way endorsed by or affiliated with Roland Corp.

Home Page:http://munt.sourceforge.net/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Guidance needed: Packaging for Fedora

oturpe opened this issue · comments

Hello,

I am trying to package Munt for Fedora. The motivation for this is the mt32emu library, but I will also attempt to package the applications. I kindly ask for guidance on how to handle Munt's monorepo approach.

For background, Fedora uses rpm packaging system. Rpm supports building once and splitting the resulting artifacts into multiple "subpackages". Initially, this seemed like a good approach for packaging Munt, since there is a top-level build script that builds all the parts. However, this ran into the following problems:

  1. It is unclear which release tarball should be chosen. We would like to have latest stable versions of everything. However, looking at the contents of releases, it looks like the named component (e.g. mt32emu for release mt32emu_2_5_1) is at specified version number, while others are Git snapshots. Is there a way to get a single release tarball that only contains release versions, not snapshots?
  2. Using the latest release munt_2_5_0 and building both mt32emu and mt32emu-qt, shared library is not built, instead static linkage is used to embed it inside mt32emu-qt. This is not what is wanted, for Fedora the correct configuration would be to build the shared object anyway, and use that with mt32emu-qt and other dependees. Is there a way to achieve this?

Another method would be to package all components separately: Start from component's latest release and build only that component. That would solve the first problem. For the second one, mt32emu shared object would be built, and the only remaining problem would be how to build the other components against that instead of static linkage.

I also have a minor complaint regarding how top-level CMakeFiles.txt sets parameters CPACK_PACKAGE_DESCRIPTION_FILE and CPACK_RESOURCE_FILE_LICENSE: Values for these are fetched from subdirectories FreeBSD and mt32emu-qt, respectively. Thus, even if only mt32emu is built, the other subdirectories have to be extracted. Of course they are there and thus everything works, but this prevents using a technique sometimes used in Fedora packaging: Removing all unused release tarball directories before building, to make sure that they are not used. This is useful e.g. to ensure that no content with unexpected licenses end up the build result.

I am willing to submit any changes that may be needed as PRs once it is clear what is the best path forward.

Hi Otto,

Thank you for the effort you spend at adding munt to Fedora project! I hope together we'll find an acceptable solution to land mt32emu and related application on Fedora.

Let me clarify the current situation with the repo and packaging, so that you might be able to suggest some improvements to make this process easier in future.

At this point, munt repo is a collection of semi-independent components, some of them never work together on a single system, but most of them have one thing in common - the use of the mt32emu library. This separation should come in handy in a GNU/Linux distribution, as this permits updating the components individually, as soon as a new release is tagged. Indeed, we strive to ensure backwards compatibility wrt. API and ABI of the library to make the update process effortless. However, we prefer to keep this single munt repo over splitting it up into submodules, etc., for personal convenience.

Note, we also tag a munt release that wraps up a development stage (i.e. a release of the library accompanied with the relevant releases of main user applications that enable the use of the new features). This is mostly intended for systems without a native packaging procedure. The relevant tarball (e.g. munt_2_5_0) is also published at SourceForge.net. Such releases should be expected to contain versions of the components aligned with each other, but relying on them may make the update cycle longer.

Taking the above into account, I'd propose to rely on the releases of individual components for Fedora and ignore the global munt tags. But as you've mentioned, we cannot guarantee that a single commit receives tags for all components at once (we used to use this approach and it's proven difficult in maintenance). Instead, each component is supposed to be updated separately, as soon as it gets released. For instance, the two RPMs relevant for libmt32emu may get updated first and deliver a bugfix or a new feature for other applications outside the munt project before a new global munt release is tagged. Then, the mt32emu-qt UI application may be updated to use the newly available features as it is released, and so on.

FYI, I plan to make quite a bit of improvements in the current CMake build process shortly, as documented in #65. It should be very possible to ensure that individual components will successfully built given a subtree of the munt sources, without stale references to irrelevant directories. I'm also going to improve configurability wrt. packaging by using CMake module GNUInstallDirs, so we'll have a well-defined set of target directories instead of some custom (random) options. I hope this will be appreciated.

BTW, the CMake build script of libmt32emu provides a handful of options to customise the build process. For example, libmt32emu_SHARED let you choose whether a shared library is to be built (also BUILD_SHARED_LIBS may be specified for that); LIB_INSTALL_DIR is useful for building a package on 64-bit systems; options libmt32emu_WITH_SYMBOL_VERSIONING and libmt32emu_WITH_VERSION_TAGGING may be used to facilitate automatic versioning of required dependencies by RPM, and so forth.

Please see if that helps.

Thank you for the detailed response. It sounds like creating separate packages for each component is the best way. I do not see any blocker for that here, so I will try it out.

One potential difficulty that comes to mind is that in Fedora, Anitya is used to automatically notify maintainers when new upstream versions for packages are available. It is not fully clear to me if Anitya can correctly interpret Munt release naming scheme. There are some release name filtering options, so it might be that it works correctly. And if it does not, it may be that Anitya simply needs to be improved to support Munt's layout. I will give it a try after I have the packages building successfully.

Thank you for pointing me to build options, those sound useful. Fedora actually recommends using symbol versioning for libraries, so it is good to see that it is supported here.

If you do not mind, I would like to keep this issue open when I create packages, just in case I run into something unexpected.

Good to hear.

If you do not mind, I would like to keep this issue open when I create packages, just in case I run into something unexpected.

No problem, feel free to continue with this issue and close it as you find appropriate.

I ran into a small issue regarding the sha1 implementation in mt32emu/src/sha1.

The first thing is that Fedora would prefer to delegate cryptographic algorithms to system libraries, i.e. OpenSSL. On the other hand, bundling single hash implementations is common in other packages too, and the purpose of that algorithm is simple file equality comparison, so I do not think there is any problem here — I am just noting this for completeness.

The actual problem is with the license of that code. It is noted as BSD 3-clause in AUTHORS.txt and the full license is included in source files. However, Fedora ships rpm packages with compiles binaries, so this item of the license needs to be considered:

Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

Since source files are not included in the binary rpm, the full license must somehow be added to the package. Would it be possible to add it somewhere in the repository, so that inclusion can be done simply by including the relevant file to package? Options include:

  • Add COPYING.txt to mt32emu/src/sha1 folder
  • Add full license text to AUTHORS.txt

No problem, will extend AUTHORS.txt in a minute.

Another thing came up during Fedora package review for mt32emu library:
In directory mt32emu,
there are two license files COPYING.txt and COPYING.LESSER.txt.
The former contains GPLv2 license text, the latter LGPLv2.1.
Actually, there is nothing that uses GPLv2,
so including that is not needed and confusing.

Note that LGPL version 3 is written as an extension to GPLv3,
in which case both licenses would be needed.
But mt32emu uses v2.1 which is written as a standalone full license.

Would it be possible to have only COPYING.txt that only contains the actual license, i.e. LGPLv2?

It is not a big problem if the current setup is preferred for some reason.
It is not difficult to adjust the Fedora package a little bit
so that the currently unused license is not packaged.

Note that LGPL version 3 is written as an extension to GPLv3,
in which case both licenses would be needed.

Ahah, that might explain it. I believe there was some confusion about adding these files. I did ask about that in the past, and the reasoning sounded exactly like that "LGPL is an extension, blah, blah".

It's completely fbm to nuke it if it's legit.

We try to follow the guidance of GNU's GPL how-to, in particular:

  • "All programs, whether they are released under the GPL or LGPL, should include the text version of the GPL"
  • "If you are releasing your program under the Lesser GPL, you should also include the text version of the LGPL, usually in a file called COPYING.LESSER. Please note that, since the LGPL is a set of additional permissions on top of the GPL, it's crucial to include both licenses so users have all the materials they need to understand their rights."

Even if LGPL v2.1 is "more stand-alone" than LGPL v3, LGPL v2.1 does still reference the standard GPL (since it's an option to distribute derivatives under that license). Therefore the guidance from the how-to seems appropriate for LGPL v2.1 as well, even if it was geared more towards LGPL v3 (which seems likely).

So, we don't currently plan to remove the copy of the GPL in COPYING.txt. But nobody's going to complain if you don't include it in the Fedora packaging where the LGPL remains and applies. Thanks for taking on this work!

Thank you, these are all valid points. As I said before, either way is acceptable from Fedora packaging perspective, and now we can link back here for explanation why Munt takes the approach it takes.

mt32emu (the library) now has an official Fedora package: rpms/mt32emu.
Thank you for the guidance,
it is a joy to do packaging work when the upstream is responsive.

Since the work is done, I close this issue now.
Later, I may package mt32emu-qt, but not right now.
I will open another issue if I need more help.

Regarding the license file question,
I just ran into a situation where LGPLv3 files were copied to otherwise LGPLv2.1 project.
According to Fedora's GPL compatibility matrix,
the only way to make this happen is to convert to GPL.
(I did not research the details of why it would be so, but that is what the matrix says.)
In such case, it is very helpful to have the exact text of the alternative license(s) available
to remove any ambiguity.
So, my suggestion of removing the alternative was bad.
Thank you @kingguppy for arguing in favor of keeping it in.