Arch Linux (AUR) package(s) for freecalypso

[Mychaela Falconia]

Hi Vadim,

> I acknowledge this, so here is a release package for gsm-codec-lib:
> https://aur.archlinux.org/packages/freecalypso-gsm-codec-lib

Thanks!  Looking closer, I see one additional issue which I haven't
had to address previously.  libgsmfrp and the utilities part of
gsm-codec-lib depend on classic libgsm - but the latter library does
not come packaged with the base system in Slackware, and the
traditional UNIX philosophy (replicated by Slackware) is that anything
that doesn't come with the base OS needs to be compiled and installed
by the local sysadmin directly from native source.  When someone
compiles and installs classic libgsm in the traditional sans-package
way (from gsm-1.0.22.tar.gz, following included Makefile instructions),
header file gsm.h ends up in /usr/local/include, to be included by
applications as <gsm.h>.

Looking at your `pacman -Ql gsm` output, I see that the people who
packaged libgsm for Arch made a different choice:

> gsm /usr/include/
> gsm /usr/include/gsm/
> gsm /usr/include/gsm/gsm.h

I see that your packaging script patches the source to include <gsm/gsm.h>
instead of plain <gsm.h> - fair enough, you are doing exactly what I
expect local builders to do on systems with different paths.  But what
about subsequent installation of gsm_fr_preproc.h and gsm_efr.h headers?
My thinking is that they should be installed in the same directory
where basic gsm.h resides, so that application programs will do:

#include <gsm.h>
#include <gsm_fr_preproc.h>
#include <gsm_efr.h>

or

#include <gsm/gsm.h>
#include <gsm/gsm_fr_preproc.h>
#include <gsm/gsm_efr.h>

depending on the system style.  Basically libgsmfrp and libgsmefr are
explicitly intended to be members of the same family as classic libgsm,
and should be installed in a consistent style.

Would it be possible to reach out to whoever maintains the classic
libgsm package for Arch and get the same person/team to add/maintain
libgsmfrp and libgsmefr packages (or a combined themwi-gsm-codec-lib
package if that's what Arch prefers) likewise?

> If we were in the Debian universe, we would have to create separate 
> packages even for libgsmefr and libgsmfrp,

Yes, that was exactly my intent in the PACKAGING guidelines document,
driven primarily by semantic versioning requirements - see semver.org
and the SemVer-related documentation bits in gsm-codec-lib source
package.

> Osmocom's libosmocore is such an example:
> https://cgit.osmocom.org/libosmocore/tree/debian/control

Yes, libosmocore is a perfect analogue from Osmocom universe to what I
did in gsm-codec-lib: one source package, but several logically
independent libraries, each with its own semantic versioning,
translating into a practical requirement for separate binary packages
with their own version numbers acting as nodes in the dependency graph.

> I also created a release package for the fc-host-tools:
>
> https://aur.archlinux.org/packages/freecalypso-tools
>
> which is based on the release tarball (r19) and does include the target 
> binaries installed under '/opt/freecalypso/target-bin'.

Looks good, thanks!  I will also be putting out r20 shortly, as
previously promised.

M~