diff PACKAGING @ 208:13d27ff5b5df

add documents for release
author Mychaela Falconia <falcon@freecalypso.org>
date Sat, 18 Feb 2023 23:24:54 +0000
parents
children 34f8549ff0b1
line wrap: on
line diff
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/PACKAGING	Sat Feb 18 23:24:54 2023 +0000
@@ -0,0 +1,60 @@
+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.
+
+themwi-pcap-utils: the set of command line utilities built in the pcap
+subdirectory, with a dependency on libpcap but no dependencies on any GSM
+libraries.
+
+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.