Arch Linux (AUR) package(s) for freecalypso

[Mychaela Falconia]

Hi Vadim,

> I see another option: installing a file to '/etc/profile.d/', which will 
> add '/opt/freecalypso/bin' to $PATH.

Thanks for the tip - I didn't realize that there is this easy way for
"modern" users to add non-standard directories to their $PATH.  (For
my own use I have that /etc/profile.d mechanism disabled, and I set my
full $PATH including /opt/freecalypso/bin in my ~/.profile - but I
don't expect the same from more casual users.)

> * 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?

> * 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.

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?

> In case anybody needs packages for other fc-repositories, just ping me!

With more turnkey-oriented parts of FreeCalypso suite - for example,
fc-am-toolkit package and its dependencies - the items in need of
distro packaging are tarball releases rather than Hg repositories.
Take for example ffs-editor, which should be considered a strict
dependency for fc-am-toolkit in packaged workflows - making a distro
package from ffs-editor Hg repository would make no sense, but making
one from ffs-editor-r2.tar.bz2 release would make perfect sense.  Then
there would be a distro package made from fc-am-toolkit-r1.tar.bz2,
having the following packages as dependencies:

* pkg made from fc-host-tools-r19.tar.bz2
* pkg made from fc-data-bundle-r1.tar.bz2
* pkg made from fc-ffs-editor-r2.tar.bz2

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.

M~