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~ _______________________________________________ Community mailing list Community@freecalypso.org https://www.freecalypso.org/mailman/listinfo/community