PKGBUILD

# NOTES: 30-MAR-17
# It has been suggested that the chirp-hg PKGBUILD is somehow different from the chirp-daily
# PKGBUILD. It is emphatically NOT. The tarball that chirp-daily uses is *automatically*
# generated from the contents of the mercurial repo whenever ANY changes that would result
# in a new runtime are entered into the hg-repo. <- ANY suggestion that the chirp-hg
# PKGBUILD is useful because it serves the (usual) purpose of a VCS PKGBUILD asks the reader
# to essentially ignore this fact.
#
# To wit; I cannot find a good reason for the current chirp-hg PKGBUILD since it cannot (as
# currently written) offer anything that the chirp-daily PKGBUILD does not. (NOT even newer
# runtime code !!)
#
# It has also been suggested that the chirp PKGBUILD (annotated below) includes additional
# runtimes that are experimental. This is pure conjecture. I do not know why they are not
# included in the release tarball (I *CAN* make an educated guess as to why), but since
# they DO work, are useful, are a part of the code base, and are NOT tagged as experimental
# or a test or ????; they are *NOT* experimental in the least way. (To suggest otherwise is
# to suggest that the end user will never need to run them and find out that they are NOT
# experimental.)
#
# To wit; The chirp PKGBUILD *is* a "COMPLETE" package. It is cited as such, AND it is
# truly complementary to the chirp-daily PKGBUILD since it includes additional runtimes.
#
# Finally, to the TU's considering the fate of these three PKGUILDs; trying to merge all
# three PKGBUILDs will only result in the (original) chirp PKGBUILD. OR trying to merge
# merge the chirp-hg and either of the other two PKGBUILDs in question will only result
# in what is already extent in the chirp and chirp-daiy PKGBUILDs.
#
# To wit; Taking into account ALL of the reasons stated above, the simple solution is to
# delete the chirp-hg PKGBUILD and keep the other two. *** And MOST IMPORTANTLY nothing
# will be any different for the end user v/v usefulness !!
#
# NOTES: 15-MAR-17
# FIVE important items to consider (now that there is a TU that is considering
# merging the three "chirp" packages; chirp (this package), chirp-daily, and chirp-hg);
#
# - The 'pkgver()' for this package allows the software to alert the user of an upgrade
# when the program is started. This is an important feature the upstream authors have
# written into the program. The "conventional" hg 'pkgver()' script (as used in the
# chirp-hg PKGBUILD) does NOT enable this feature.
#
# - The 'prepare()' for this package is also required for this "alert' feature to work.
# Again the prepare() in the "chirp-hg" PKGBUILD will not allow this to work.
#
# - There are numerous examples of packages that use vcs repos but for various reasons
# do NOT use "-<whatever/vcs>" in the 'pkgname=' as there are no stable release and therefor
# no need to differentiate it from another PKGBUILD that represents the 'stable-release'.
#
# - The current "chirp-hg" and "chirp-daily" PKGBUILDs do not install ALL of available binaries
# and their associated help-documentation as THIS PKGBUILD does.
#
# - The "chirp" PKGBUILD has been part of the aur for a very long time (8 years ???).
# The "chirp-daily" and "chirp-hg" PKGBUILDS are *much* newer. Merging ALL three PKGBUILDs will
# not accomplish anything of value since ALL of the code in ALL three of the current PKGBUILDS
# comes from the very same upstream repo. (** The tarball that "chirp-daily" uses is automatically
# generated whenever this upstream repo is changed BUT does not contain all of the upstream coding.)
#
#
# SUGGESTIONS for the TUs.
#
# ^^^^ What is to be done then ? Well, the chirp-hg repo is redundant, newer, and does NOT
# have anything to offer that this PKGBUILD doesn't have. Any decision on merging
# should take this into account. Since the "Maintainer:" of the "chirp-hg" PKGBUILD is cited in
# two places below, his PKGBUILD can be "merged" into this one. (And I would suggest leaving
# the chirp-daily PKGBUILD as is, as it *DOES* represent a working verion (albeit incomplete).
#
#
# Maintainer: not_anonymous <nmlibertarian@gmail.com>
# Contributor: Erez Raviv (erezraviv@gmail.com)
# Contributor: Mathew Hiles (matthew.hiles@gmail.com)
# Contributor: David Thurstenson thurstylark@gmail.com
# Contributor: Nicholas Tryon (KC2YTG) <dhraak at gmail dot com>
		# I would hope all package Maintainers would eagerly seek out all
		# previous contributors to the packages. So..I am restoring those
		# names I can find AND adding the names of the contributors to
		# the chirp-hg & chirp-daily PKGBUILDS .

pkgname=chirp
		# Although this package is sourced from an hg repo, the authors do NOT distribute
		# "releases". Instead automatically generated  tarballs that are created
		# **EVERY** time there is **ANY** change in the hg-repo. Also see the notes above.
pkgver=20170322
		# Because the automatic releases mentioned above are referenced by date; I am using
		# the same coding in pkgver() & prepare() that the upstream authors are using to tag
		# the tarball releases. More on the internal tagging (Help-About, for instance)
		# below in comments in the prepare(), AND in the notes above.
pkgrel=1
pkgdesc="GUI tool for programming Ham Radios - COMPLETE version"
		# "COMPLETE" i.e. contains ALL of the docs and executables as mentioned below
		# in package(). Although the hg-repo has all the docs and binaries the author's
		# recommended install procedure does NOT install all of them !! (Go figure..)
		# Please see the comments below in package() .
arch=('any')
url="http://chirp.danplanet.com/"
license=('GPL3')
depends=('python2-lxml' 'python2-pyserial' 'pygtk' 'hamradio-menus')
		# The upstream author's (included) .desktop file will not be used UNLESS the
		# associated 'hamradio-menus' package is installed. ** so..'hamradio-menus' really
		# isn't an optdepends. & 'desktop-file-utils' is already in the dep. tree w/ the
		# inclusion of 'hamradio-menus' .
makedepends=('mercurial')
options=('!emptydirs')
provides=('chirp')
conflicts=('chirp-daily' 'chirp-hg')
install=$pkgname.install
		# This file has important instructions to the end user on how to get control over
		# the serial ports, hence it is included.
source=("$pkgname::hg+http://d-rats.com/hg/$pkgname.hg")

pkgver() {
	cd $srcdir/$pkgname

	date +%Y%m%d
		# The upstream authors automatically use dating everywhere else.
		# Please also see the notes above in pkgver= & below in the prepare() as well as
		# the notes above. *** NOTE; This causes NO problems with bug-reports sent upstream
		# as the authors of the source REQUIRE all bug reports to be submitted on the latest
		# version. And running this PKGBUILD script prior to reporting bugs *automatically*
		# satisfies this requirement.
		# ******** AND using the 'chirp-daily' PKGBUILD will NOT, necessarily, solve this
		# requirement !! ******** (As it must have it's pkgver() updated manually before
		# it is run to match the requirement of assuring the lastest upstream version. !!!)
}

prepare() {
	cd $srcdir/$pkgname

	sed -i -e 's|/usr/sbin|/usr/bin|g' setup.py
		# Good idea de: David Thurstenson thurstylark@gmail.com
	sed -i 's:python:python2:' chirpc
		# Runs better this way !! (More especially if you also have python(3) installed.)

	date +%Y%m%d > build/version
	export VERSION=$(cat build/version)
	sed -i -e 's/^CHIRP_VERSION.*$/CHIRP_VERSION=\"'$VERSION'-arch-dev\"/' chirp/__init__.py
		# This coding above is the SAME coding as the authors' are using when
		# creating their "daily-release" tarballs, and seemed VERY approriate to use here.
		#
		# It does a couple of important things;
		# - Enables the use of an included software feature that alerts the user of a new
		# release.
		# - Replaces the tag shown in the Help-About window. This tag is from when the
		# authors were using this upstream repo for unstable development work.
		# (This repo tagging has never been changed, and still shows version 0.3.0-dev..
		# and the last stable release was 0.4.1 !!! <- It appears that this software is NOW
		# using a "rolling release" model and the "stable-release" model has been abandoned.)
}

build() {
	cd $srcdir/$pkgname

	python2 setup.py build
		# 'grep python2 setup.py build -r /var/abs' will show this is a great way to
		# handle python builds !! It can also prevent some odd/unwelcomed runtime behavior
		# if there was only the "setup.py install" invocation as used below in package() .
}

package() {
	cd $srcdir/$pkgname

	python2 setup.py install --root="$pkgdir/" --optimize=1

	install -m755 chirpc $pkgdir/usr/bin
		# A *very* cool binary that is not included when using the '...setup.py install...'
		# And for some unknown reason this is also left out of the upstream tarballs that
		# are used in the chirp-daily arch package !  In fact several useful exec. binaries
		# are left out of the chirp-daily's upstream tarball but are in the hg-repos.
		# ^^^ Go figure !!

	rm -rf $pkgdir/usr/share/doc/$pkgname/COPYING
		# This license is already installed in correct location. This is both redundant
		# and un-necessary in archlinux.
	install -m644 README.chirpc $pkgdir/usr/share/doc/$pkgname
	install -m644 README.rpttool $pkgdir/usr/share/doc/$pkgname
		# Docs that are NOT installed for included binaires when using the
		# '...setup.py install...' (They are the ONLY form of docs for these binaries !)
}
md5sums=('SKIP')
sha256sums=('SKIP')