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~ _______________________________________________ Community mailing list [email protected] https://www.freecalypso.org/mailman/listinfo/community
