Advertisement
not_anonymous

PKGBUILD

Mar 8th, 2017
199
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. # NOTES: 30-MAR-17
  2. # It has been suggested that the chirp-hg PKGBUILD is somehow different from the chirp-daily
  3. # PKGBUILD. It is emphatically NOT. The tarball that chirp-daily uses is *automatically*
  4. # generated from the contents of the mercurial repo whenever ANY changes that would result
  5. # in a new runtime are entered into the hg-repo. <- ANY suggestion that the chirp-hg
  6. # PKGBUILD is useful because it serves the (usual) purpose of a VCS PKGBUILD asks the reader
  7. # to essentially ignore this fact.
  8. #
  9. # To wit; I cannot find a good reason for the current chirp-hg PKGBUILD since it cannot (as
  10. # currently written) offer anything that the chirp-daily PKGBUILD does not. (NOT even newer
  11. # runtime code !!)
  12. #
  13. # It has also been suggested that the chirp PKGBUILD (annotated below) includes additional
  14. # runtimes that are experimental. This is pure conjecture. I do not know why they are not
  15. # included in the release tarball (I *CAN* make an educated guess as to why), but since
  16. # they DO work, are useful, are a part of the code base, and are NOT tagged as experimental
  17. # or a test or ????; they are *NOT* experimental in the least way. (To suggest otherwise is
  18. # to suggest that the end user will never need to run them and find out that they are NOT
  19. # experimental.)
  20. #
  21. # To wit; The chirp PKGBUILD *is* a "COMPLETE" package. It is cited as such, AND it is
  22. # truly complementary to the chirp-daily PKGBUILD since it includes additional runtimes.
  23. #
  24. # Finally, to the TU's considering the fate of these three PKGUILDs; trying to merge all
  25. # three PKGBUILDs will only result in the (original) chirp PKGBUILD. OR trying to merge
  26. # merge the chirp-hg and either of the other two PKGBUILDs in question will only result
  27. # in what is already extent in the chirp and chirp-daiy PKGBUILDs.
  28. #
  29. # To wit; Taking into account ALL of the reasons stated above, the simple solution is to
  30. # delete the chirp-hg PKGBUILD and keep the other two. *** And MOST IMPORTANTLY nothing
  31. # will be any different for the end user v/v usefulness !!
  32. #
  33. # NOTES: 15-MAR-17
  34. # FIVE important items to consider (now that there is a TU that is considering
  35. # merging the three "chirp" packages; chirp (this package), chirp-daily, and chirp-hg);
  36. #
  37. # - The 'pkgver()' for this package allows the software to alert the user of an upgrade
  38. # when the program is started. This is an important feature the upstream authors have
  39. # written into the program. The "conventional" hg 'pkgver()' script (as used in the
  40. # chirp-hg PKGBUILD) does NOT enable this feature.
  41. #
  42. # - The 'prepare()' for this package is also required for this "alert' feature to work.
  43. # Again the prepare() in the "chirp-hg" PKGBUILD will not allow this to work.
  44. #
  45. # - There are numerous examples of packages that use vcs repos but for various reasons
  46. # do NOT use "-<whatever/vcs>" in the 'pkgname=' as there are no stable release and therefor
  47. # no need to differentiate it from another PKGBUILD that represents the 'stable-release'.
  48. #
  49. # - The current "chirp-hg" and "chirp-daily" PKGBUILDs do not install ALL of available binaries
  50. # and their associated help-documentation as THIS PKGBUILD does.
  51. #
  52. # - The "chirp" PKGBUILD has been part of the aur for a very long time (8 years ???).
  53. # The "chirp-daily" and "chirp-hg" PKGBUILDS are *much* newer. Merging ALL three PKGBUILDs will
  54. # not accomplish anything of value since ALL of the code in ALL three of the current PKGBUILDS
  55. # comes from the very same upstream repo. (** The tarball that "chirp-daily" uses is automatically
  56. # generated whenever this upstream repo is changed BUT does not contain all of the upstream coding.)
  57. #
  58. #
  59. # SUGGESTIONS for the TUs.
  60. #
  61. # ^^^^ What is to be done then ? Well, the chirp-hg repo is redundant, newer, and does NOT
  62. # have anything to offer that this PKGBUILD doesn't have. Any decision on merging
  63. # should take this into account. Since the "Maintainer:" of the "chirp-hg" PKGBUILD is cited in
  64. # two places below, his PKGBUILD can be "merged" into this one. (And I would suggest leaving
  65. # the chirp-daily PKGBUILD as is, as it *DOES* represent a working verion (albeit incomplete).
  66. #
  67. #
  68. # Maintainer: not_anonymous <nmlibertarian@gmail.com>
  69. # Contributor: Erez Raviv (erezraviv@gmail.com)
  70. # Contributor: Mathew Hiles (matthew.hiles@gmail.com)
  71. # Contributor: David Thurstenson thurstylark@gmail.com
  72. # Contributor: Nicholas Tryon (KC2YTG) <dhraak at gmail dot com>
  73. # I would hope all package Maintainers would eagerly seek out all
  74. # previous contributors to the packages. So..I am restoring those
  75. # names I can find AND adding the names of the contributors to
  76. # the chirp-hg & chirp-daily PKGBUILDS .
  77.  
  78. pkgname=chirp
  79. # Although this package is sourced from an hg repo, the authors do NOT distribute
  80. # "releases". Instead automatically generated tarballs that are created
  81. # **EVERY** time there is **ANY** change in the hg-repo. Also see the notes above.
  82. pkgver=20170322
  83. # Because the automatic releases mentioned above are referenced by date; I am using
  84. # the same coding in pkgver() & prepare() that the upstream authors are using to tag
  85. # the tarball releases. More on the internal tagging (Help-About, for instance)
  86. # below in comments in the prepare(), AND in the notes above.
  87. pkgrel=1
  88. pkgdesc="GUI tool for programming Ham Radios - COMPLETE version"
  89. # "COMPLETE" i.e. contains ALL of the docs and executables as mentioned below
  90. # in package(). Although the hg-repo has all the docs and binaries the author's
  91. # recommended install procedure does NOT install all of them !! (Go figure..)
  92. # Please see the comments below in package() .
  93. arch=('any')
  94. url="http://chirp.danplanet.com/"
  95. license=('GPL3')
  96. depends=('python2-lxml' 'python2-pyserial' 'pygtk' 'hamradio-menus')
  97. # The upstream author's (included) .desktop file will not be used UNLESS the
  98. # associated 'hamradio-menus' package is installed. ** so..'hamradio-menus' really
  99. # isn't an optdepends. & 'desktop-file-utils' is already in the dep. tree w/ the
  100. # inclusion of 'hamradio-menus' .
  101. makedepends=('mercurial')
  102. options=('!emptydirs')
  103. provides=('chirp')
  104. conflicts=('chirp-daily' 'chirp-hg')
  105. install=$pkgname.install
  106. # This file has important instructions to the end user on how to get control over
  107. # the serial ports, hence it is included.
  108. source=("$pkgname::hg+http://d-rats.com/hg/$pkgname.hg")
  109.  
  110. pkgver() {
  111. cd $srcdir/$pkgname
  112.  
  113. date +%Y%m%d
  114. # The upstream authors automatically use dating everywhere else.
  115. # Please also see the notes above in pkgver= & below in the prepare() as well as
  116. # the notes above. *** NOTE; This causes NO problems with bug-reports sent upstream
  117. # as the authors of the source REQUIRE all bug reports to be submitted on the latest
  118. # version. And running this PKGBUILD script prior to reporting bugs *automatically*
  119. # satisfies this requirement.
  120. # ******** AND using the 'chirp-daily' PKGBUILD will NOT, necessarily, solve this
  121. # requirement !! ******** (As it must have it's pkgver() updated manually before
  122. # it is run to match the requirement of assuring the lastest upstream version. !!!)
  123. }
  124.  
  125. prepare() {
  126. cd $srcdir/$pkgname
  127.  
  128. sed -i -e 's|/usr/sbin|/usr/bin|g' setup.py
  129. # Good idea de: David Thurstenson thurstylark@gmail.com
  130. sed -i 's:python:python2:' chirpc
  131. # Runs better this way !! (More especially if you also have python(3) installed.)
  132.  
  133. date +%Y%m%d > build/version
  134. export VERSION=$(cat build/version)
  135. sed -i -e 's/^CHIRP_VERSION.*$/CHIRP_VERSION=\"'$VERSION'-arch-dev\"/' chirp/__init__.py
  136. # This coding above is the SAME coding as the authors' are using when
  137. # creating their "daily-release" tarballs, and seemed VERY approriate to use here.
  138. #
  139. # It does a couple of important things;
  140. # - Enables the use of an included software feature that alerts the user of a new
  141. # release.
  142. # - Replaces the tag shown in the Help-About window. This tag is from when the
  143. # authors were using this upstream repo for unstable development work.
  144. # (This repo tagging has never been changed, and still shows version 0.3.0-dev..
  145. # and the last stable release was 0.4.1 !!! <- It appears that this software is NOW
  146. # using a "rolling release" model and the "stable-release" model has been abandoned.)
  147. }
  148.  
  149. build() {
  150. cd $srcdir/$pkgname
  151.  
  152. python2 setup.py build
  153. # 'grep python2 setup.py build -r /var/abs' will show this is a great way to
  154. # handle python builds !! It can also prevent some odd/unwelcomed runtime behavior
  155. # if there was only the "setup.py install" invocation as used below in package() .
  156. }
  157.  
  158. package() {
  159. cd $srcdir/$pkgname
  160.  
  161. python2 setup.py install --root="$pkgdir/" --optimize=1
  162.  
  163. install -m755 chirpc $pkgdir/usr/bin
  164. # A *very* cool binary that is not included when using the '...setup.py install...'
  165. # And for some unknown reason this is also left out of the upstream tarballs that
  166. # are used in the chirp-daily arch package ! In fact several useful exec. binaries
  167. # are left out of the chirp-daily's upstream tarball but are in the hg-repos.
  168. # ^^^ Go figure !!
  169.  
  170. rm -rf $pkgdir/usr/share/doc/$pkgname/COPYING
  171. # This license is already installed in correct location. This is both redundant
  172. # and un-necessary in archlinux.
  173. install -m644 README.chirpc $pkgdir/usr/share/doc/$pkgname
  174. install -m644 README.rpttool $pkgdir/usr/share/doc/$pkgname
  175. # Docs that are NOT installed for included binaires when using the
  176. # '...setup.py install...' (They are the ONLY form of docs for these binaries !)
  177. }
  178. md5sums=('SKIP')
  179. sha256sums=('SKIP')
Advertisement
RAW Paste Data Copied
Advertisement