view PACKAGING @ 263:ffdcdb27d673

libgsmfr2: integrate e/d state from TU-Berlin code
author Mychaela Falconia <falcon@freecalypso.org>
date Sat, 13 Apr 2024 01:10:37 +0000
parents 34f8549ff0b1
children 4c458145e793
line wrap: on
line source

The present document is intended to be a guide for any parties who are going to
turn the present upstream gsm-codec-lib source package into user-friendly binary
packages for specific distributions.

The Mother's primary recommendation with regard to downstream packaging of the
present software is that end-user binary packages should be divided more finely
than the present source package.  At the present source level the two principal
libraries (libgsmefr and libgsmfrp) are combined together with a bunch of
command line utilities for reasons of compile-time dependency (utilities depend
on libraries), and also for the purposes of library development and testing -
but the same combination does not make much sense from a user's perspective.
Therefore, it is our recommendation that the present source package be split as
follows at the level of end-user distro packages:

libgsmefr package: just libgsmefr.a and its associated gsm_efr.h header file.

libgsmfrp package: just libgsmfrp.a and its associated gsm_fr_preproc.h header
file.  Given that <gsm_fr_preproc.h> depends on <gsm.h> from classic libgsm,
the latter library (libgsm) should probably be officially declared as a
dependency for libgsmfrp.

gsm-codec-utils (or themwi-gsm-codec-utils or themwi-codec-utils) package: all
command line utilities built and installed in amrconv, efrtest, frtest and
miscutil subdirectories.  This package will depend on libgsmefr, libgsmfrp and
classic libgsm - the latter is pre-existing software, not provided by
Themyscira.

With the division recommended above, the set of end-user packages will exhibit
a sensible functional division from the user's perspective, and a clean and
sensible dependency graph.

Package versions
================

The two library packages (libgsmefr and libgsmfrp) should be versioned with
their own proper semantic versions listed in the Library-versions document, as
opposed to the larger gsm-codec-lib tarball release version.  If a later
gsm-codec-lib tarball release exhibits no changes in the libraries (the only
changes are in the command line utilities) or if only one of the two libraries
exhibits changes (as indicated with a new semantic version), then NO new
downstream packages should be made for unchanged libraries - instead already
made binary packages for that library version (SemVer) should be retained.

Downstream package version numbers for command line utilities packages are up
to the discretion of packaging maintainers; using gsm-codec-lib tarball release
numbers is acceptable.

Patience, please
================

Please make downstream package releases *only* from officially published tarball
releases of gsm-codec-lib - please do *not* make packaged builds or "releases"
from our Mercurial repository.  Any time we have a new development that is
expected to be useful to downstream end users, we shall make a proper tarball
release, and if there are any changes in the libraries, we shall assign new
semantic versions as appropriate.