Hello fmod developers,
I’d like to package fmodapi for the Debian non-free section.
Does the fmodapi license allow that? In the non-free section it
will not be part of the core Debian distribution as it is released on
CD. But the packages would be uploaded to the Debian FTP servers
and mirrors that host the non-free section.
Sorry if this has been answered somewhere in the past but I searched the forum and only
found this thread from 2004 viewtopic.php?f=2&t=3881
which deals with debian packaging. Unfortunately it doesn’t say anything about license issues.
Apart from that there is a technical issue with the libraries themselves: they do not have any SONAMEs
but that’s required by the Debian policy (and would be a good thing anyway I guess 😉
I’d like to package version 4.26.x because that’s the one zdoom needs at the moment.
As I understand version ‘4.26’, ‘4.27’, etc. are not binary compatible, so the libraries would
need to be named
libfmodex4.26.so.26.34 (symlinked to libfmodex4.26.so.26, SONAME "libfmodex4.26.so.26")
libfmodex4.28.so.28.24 (symlinked to libfmodex4.28.so.28, SONAME "libfmodex4.28.so.28")
libfmodex4.30.so.30.15 (symlinked to libfmodex4.30.so.15, SONAME "libfmodex4.30.so.15")
This way different fmodapi versions could be installed at the same time.
Would it be possible to add that in the next minor releases?
- johey asked 7 years ago
Thanks for the kind wishes, I am back now
Regarding packaging FMOD for distribution, we generally recommend FMOD is not installed this way. The preferred usage of FMOD is for a single version to ship with the application or game and remain next the executable. FMOD isn’t really designed with the idea of hot swapping newer versions of the libs in to replace older ones.
Our build system isn’t currently setup to discriminate between dev branch (where minor releases aren’t binary compatible) and stable branch (where minor releases are compatible). Also some developers do version checks inside their code (as our examples do) which makes swapping out libs not possible.
With regards to your licensing question, your best bet would be to write to email@example.com to get official approval.
about the technical issue: thanks for the clarification about the stable and
development versions. So how about adding the SONAME only to the stable
releases (I.e. "libfmodex4.26.so.26" 4.26.xx)? If I understand it right that
should be no problem because the abi does not change in the stable branch.
About the license: in viewtopic.php?f=7&t=13383&p=46499&hilit=linux#p46499 you said that fmod should be packaged and shipped together
with the software that needs it.
That’s what I’m trying to do: packaging zdoom and fmod for Debian 😉
But without an explicit ok from your side in the license to upload it to a
public ftp/http-server (like the Debian non-free archive) the Debian people
will not let me do it.
Thanks for your help so far, I’m really hoping to get a positive answer in this
Our version numbers are a guide to developers mostly, so 4.26.00 should be binary compatible with 4.26.34. If the version number is odd then the sub versions are not binary compatible, for instance 4.27.00 may not be compatible with 4.27.35. Many developers once they reach lock down only want to take fixes not features, so we ensure that features only go into development (odd) versions not stable (even) versions, all supported versions get fixes.
Regarding the license situation, we prefer to have the files hosted on our own site.
so I undestand that there is no guarantee that for example 4.26.33 and 4.26.34 are binary compatible?
If that’s the case then why do you have that numbering in the first place?
Even more importantly I need information about the license situation. Could you
tell me if the current license is allowing an upload into to the non-free section of the Debian archive?
Thanks a lot!
Please login first to submit.