comparison PACKAGING @ 456:4c458145e793

PACKAGING: new guidelines
author Mychaela Falconia <falcon@freecalypso.org>
date Fri, 10 May 2024 07:35:36 +0000
parents 34f8549ff0b1
children a53225b44ea5
comparison
equal deleted inserted replaced
455:287063b9cf43 456:4c458145e793
1 The present document is intended to be a guide for any parties who are going to 1 The present document is intended to be a guide for any parties who are going to
2 turn the present upstream gsm-codec-lib source package into user-friendly binary 2 turn the present upstream gsm-codec-lib source package into user-friendly binary
3 packages for specific distributions. 3 packages for specific distributions.
4 4
5 The Mother's primary recommendation with regard to downstream packaging of the 5 Naming and attribution
6 present software is that end-user binary packages should be divided more finely 6 ======================
7 than the present source package. At the present source level the two principal
8 libraries (libgsmefr and libgsmfrp) are combined together with a bunch of
9 command line utilities for reasons of compile-time dependency (utilities depend
10 on libraries), and also for the purposes of library development and testing -
11 but the same combination does not make much sense from a user's perspective.
12 Therefore, it is our recommendation that the present source package be split as
13 follows at the level of end-user distro packages:
14 7
15 libgsmefr package: just libgsmefr.a and its associated gsm_efr.h header file. 8 Please note that the present GSM codec libraries and utilities suite should be
9 properly classified as Themyscira software and not FreeCalypso. Even though
10 FreeCalypso and Themyscira software realms currently have the same maintainer,
11 the two realms have different conventions that matter for packaging and
12 configuration management:
16 13
17 libgsmfrp package: just libgsmfrp.a and its associated gsm_fr_preproc.h header 14 * FreeCalypso software components are intended for users and tinkerers who work
18 file. Given that <gsm_fr_preproc.h> depends on <gsm.h> from classic libgsm, 15 with GSM phone handsets, GSM MS development boards, SIM cards and related
19 the latter library (libgsm) should probably be officially declared as a 16 mobile-side hardware. That software realm uses a fixed /opt/freecalypso
20 dependency for libgsmfrp. 17 directory hierarchy, non-FHS, which cannot be changed.
21 18
22 gsm-codec-utils (or themwi-gsm-codec-utils or themwi-codec-utils) package: all 19 * Themyscira software components are intended to run on server machines where
23 command line utilities built and installed in amrconv, efrtest, frtest and 20 they will often need to interwork closely with Osmocom and other network
24 miscutil subdirectories. This package will depend on libgsmefr, libgsmfrp and 21 software. Unlike FC, ThemWi software does _not_ require a fixed install
25 classic libgsm - the latter is pre-existing software, not provided by 22 location; the Mother's home environment uses /opt/themwi by default (although
26 Themyscira. 23 even here we sometimes have to work with multiple installs like /opt/themwi2
24 etc), but the intent is that users of ThemWi software should have just as much
25 freedom to choose their install location as users of Osmocom CNI.
27 26
28 With the division recommended above, the set of end-user packages will exhibit 27 Toward this end, all ThemWi software beginning with the present package will
29 a sensible functional division from the user's perspective, and a clean and 28 have a ./configure script (hand-coded, no Autotools) that accepts the standard
30 sensible dependency graph. 29 --prefix option, allowing the install prefix to be chosen freely.
30
31 Note that DESTDIR= setting on 'make install' is now supported! What is the
32 difference between --prefix argument to ./configure and DESTDIR= on the 'make
33 install' command? Answer: --prefix indicates the final location where the
34 software is meant to reside in its installed state, DESTDIR= is a local
35 modification for the 'make install' operation only, intended for staged installs
36 as happen in package build scripts.
37
38 Package splitting
39 =================
40
41 There are several different ways how the full GSM codec libraries and utilities
42 suite may be kept together or divided in binary packages:
43
44 1) The simplest way is to have one binary package built from the source package,
45 containing all libraries and utilities.
46
47 2) The next option is to produce one package with libraries and a second package
48 with utilities. The utilities package will then depend on the libraries
49 package, but not the other way around.
50
51 3) The finest division would be to produce a separate package for each codec
52 library (libgsmefr, libgsmfr2, libtwamr) and then a utilities package. The
53 set of utilities included in the present suite does not have clear-cut
54 logical divisions, hence it would probably make the most sense to have just
55 one utilities packages that depends on all of the libraries.
56
57 The choice of approach is left to the discretion of individual packagers or
58 package maintainers.
31 59
32 Package versions 60 Package versions
33 ================ 61 ================
34 62
35 The two library packages (libgsmefr and libgsmfrp) should be versioned with 63 If separate packages are made for each codec library, these packages should be
36 their own proper semantic versions listed in the Library-versions document, as 64 versioned with their own proper semantic versions listed in the Library-versions
37 opposed to the larger gsm-codec-lib tarball release version. If a later 65 document, as opposed to the larger gsm-codec-lib tarball release version. If a
38 gsm-codec-lib tarball release exhibits no changes in the libraries (the only 66 later gsm-codec-lib tarball release exhibits no changes in the libraries (the
39 changes are in the command line utilities) or if only one of the two libraries 67 only changes are in the command line utilities) or if only some of the libraries
40 exhibits changes (as indicated with a new semantic version), then NO new 68 exhibit changes (as indicated with a new semantic version), then NO new
41 downstream packages should be made for unchanged libraries - instead already 69 downstream packages should be made for unchanged libraries - instead already
42 made binary packages for that library version (SemVer) should be retained. 70 made binary packages for that library version (SemVer) should be retained.
43 71
44 Downstream package version numbers for command line utilities packages are up 72 Downstream package version numbers for command line utilities packages are up
45 to the discretion of packaging maintainers; using gsm-codec-lib tarball release 73 to the discretion of packaging maintainers; using gsm-codec-lib tarball release