FreeCalypso > hg > gsm-codec-lib
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 |