Arch Linux (AUR) package(s) for freecalypso

[Vadim Yanitskiy]

Hi Mychaela,

On 01.09.2023 07:23, Mychaela Falconia wrote:
>> *https://aur.archlinux.org/packages/freecalypso-sim-tools-hg
>> *https://aur.archlinux.org/packages/freecalypso-ota-tools-hg
>> *https://aur.archlinux.org/packages/freecalypso-sms-coding-utils-hg
> I confirm that these 3 repositories are intended to remain rolling
> release, meaning that I don't make tarball releases for those sw
> components.  However, I have a question about how AUR PKGBUILD files
> work in the case of Hg repository source - if a casual user simply
> runs your PKGBUILD script, will it compile the latest Hg tip, or the
> specific revision referenced in the AUR package?

these PKGBUILD scripts will always build the latest Hg tip, right.  The 
static $pkgver in these packages is not really important, it gets 
overwritten by the pkgver() function when running makepkg.

>> *https://aur.archlinux.org/packages/freecalypso-gsm-codec-lib-hg
> The current Hg tip of gsm-codec-lib corresponds to gsm-codec-lib-r2.tar.bz2
> formal release; given the importance of stability in the case of a
> library package that is meant to be used as a dependency by other sw,
> I would really like to see distro packages based on tarball releases
> rather than Hg tip in this case.

I acknowledge this, so here is a release package for gsm-codec-lib:

https://aur.archlinux.org/packages/freecalypso-gsm-codec-lib

> Also what are your thoughts regarding library vs utils splitting which
> I outlined in the PACKAGING file in the gsm-codec-lib source tree?  I
> admit that I have no experience with the world of distro packaging,
> hence I would like feedback from someone who does have a good grasp of
> that world - are those PACKAGING guidelines reasonable (and if so, why
> are they not being followed), or are they totally unreasonable and in
> need of changing to better fit the real world of how distro packaging
> is done?

It should be said that I am not an experienced packager either ;)  From 
what I can tell, unlike with Debian packages, in which every library is 
a separate package plus the '-doc' and '-dbg' variants, Arch packages 
(even official ones) follow 'all-in-one' strategy.  For instance, take a 
look at the 'gsm' package, which is a dependency of gsm-codec-lib:

https://archlinux.org/packages/extra/x86_64/gsm/
https://gitlab.archlinux.org/archlinux/packaging/packages/gsm/-/blob/main/PKGBUILD?ref_type=heads

$ pacman -Ql gsm
gsm /usr/
gsm /usr/bin/
gsm /usr/bin/tcat
gsm /usr/bin/toast
gsm /usr/bin/untoast
gsm /usr/include/
gsm /usr/include/gsm/
gsm /usr/include/gsm/gsm.h
gsm /usr/lib/
gsm /usr/lib/libgsm.so
gsm /usr/lib/libgsm.so.1
gsm /usr/lib/libgsm.so.1.0.22
gsm /usr/share/
gsm /usr/share/licenses/
gsm /usr/share/licenses/gsm/
gsm /usr/share/licenses/gsm/license.txt
gsm /usr/share/man/
gsm /usr/share/man/man1/
gsm /usr/share/man/man1/toast.1.gz
gsm /usr/share/man/man3/
gsm /usr/share/man/man3/gsm.3.gz
gsm /usr/share/man/man3/gsm_explode.3.gz
gsm /usr/share/man/man3/gsm_option.3.gz
gsm /usr/share/man/man3/gsm_print.3.gz

As can be seen, this includes both libraries and binaries without any 
separation.  So going back to gsm-codec-lib, I think it's fine to have 
everything in one package.

If we were in the Debian universe, we would have to create separate 
packages even for libgsmefr and libgsmfrp, plus their usual variations: 
'-dev', '-dbg', '-doc'...  Osmocom's libosmocore is such an example:

https://cgit.osmocom.org/libosmocore/tree/debian/control

> The common theme between fc-host-tools and ffs-editor is that Calypso
> target binaries are involved, installed under /opt/freecalypso/target-bin.
> It would be a debug and support nightmare if casual end users were to
> compile these from source just for the heck of it (toolchain differences
> and whatnot), hence my philosophy is that you should only compile those
> parts from source if you are putting on the hat of a developer.  Distro
> packages made for "end user mode" should be made from tarball releases
> that include prebuilt target binaries.

Indeed, the '/opt/freecalypso/target-bin' directory is missing in the 
'-hg' package.  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'.

-- 
Best regards,
Vadim.