Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- # 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')
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement