apache-ant 1.10.2 PKGBUILD discussion

rgcv · 2018-02-21 08:09:35

TL;DR: Made a hacky working PKGBUILD for apache-ant 1.10.2, potential temporary replacement for the one found in the extra repository. Looking for any kind of feedback/help, much appreciated.

So I recently got to using ant a tad bit and noticed the version in the extras repo has been flagged out of date.

I've looked around but I couldn't quite find an alternative or a solution this. I did find a post in apache-ant is obsolete where Lone_Wolf proposes a PKGBUILD derived from the existing one (at time of writing) @extra/apache-ant.

After trying to use it to build the ant package, it failed, reporting it could find some artifacts in the maven central, namely jai-core, jai-codec, xz (EDIT: xz is available in repo1, the default ant uses, but wouldn't get hit because the lib fetching would fail at jai-core) and NetRexx. Found this after many hours of bashing my head against countless walls and came up with the following PKGBUILD myself:

# Maintainer: Guillaume ALAUX <guillaume@archlinux.org>
# Contributor: Andrew Wright <andreww@photism.org>
# Contributor: Paul Mattal <paul@archlinux.org>
pkgbase=apache-ant
pkgname=('apache-ant' 'apache-ant-doc')
pkgver=1.10.2
pkgrel=1
arch=('any')
url='https://ant.apache.org/'
license=('APACHE')
makedepends=('java-environment=8' 'junit')
source=(
  https://apache.org/dist/ant/source/${pkgbase}-${pkgver}-src.tar.bz2{,.asc}
  https://repository.jboss.org/nexus/service/local/repositories/thirdparty-releases/content/javax/media/jai-core/1.1.3/jai-core-1.1.3.jar
  https://repository.jboss.org/nexus/service/local/repositories/thirdparty-releases/content/com/sun/media/jai-codec/1.1.3/jai-codec-1.1.3.jar
  http://central.maven.org/maven2/org/tukaani/xz/1.0/xz-1.0.jar
  http://www.netrexx.org/files/NetRexx-3.06-GA.zip # No checksum publicly available..
  ant.conf
  apache-ant.csh
  apache-ant.install
  apache-ant.sh
  bin_ant
)
validpgpkeys=(
  '61B656E44615E2AEF78E8DCF0E69F809710038F5' # Antoine Levy-Lambert <antoine@apache.org> (2010)
  '06A228AAB83A18A8DF7B84B08614D6AB265B4C63' # ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (2003)
  'F19E751B68B907C4F2E6B7B18D6D0AD09711DBFC' # Jon Schneider <jschneider@apache.org> (2010)
  '5CDF153E81AB0522A1E5BFBE483C23C67BF8BE8E' # Nicolas Lalevée <nicolas.lalevee@hibnet.org> (2008)
  '9C60C6B3A5A9DF8FEDD299D65BE0BA8CB80602AE' # Maarten Coene <maartenc@apache.org> (2008)
  '14604968898CEB74A5329360AEB01A153B7C75B1' # Gilles Scokart <gscokart@apache.org> (2007)
  '07C69F931EE82E694E73B54203F68CBDDE8884A0' # Xavier Hanin <xavier.hanin@gmail.com> (2007)
  'F54C925C2454F21D86692540A0BFF93DAA0077B0' # Kev Jackson <kevj@apache.org> (2006)
  'B36135CBA375AA1ADE562A1C6E947594C152431A' # Steve Loughran <stevel@apache.org> (2005)
  '06A228AAB83A18A8DF7B84B08614D6AB265B4C63' # Antoine Levy-Lambert <antoine@apache.org> (2003)
  '47309207D818FFD8DCD3F83F1931D684307A10A5' # Henri Gomez <hgomez@users.sourceforge.net> (2002)
  '5F35E131F832ED23F761578BEFA3E779EDF62C35' # Magesh Umasankar <umagesh@apache.org> (2002)
  '5B1E231C400B113C061C26508104644F51898504' # Conor MacNeill <conor@apache.org> (2001)
  'CE8075A251547BEE249BC151A2115AE15F6B8B72' # Stefan Bodewig <bodewig@apache.org> (2001)
)
sha512sums=(
  'ad183d94e1a284719c3c83b8ae4049be0ee7867fd777017f0de8b887d03089925d198d5002a0526d781917ef32a37264018cf90ed8e8a60399f3b64aa87419bb'
  'SKIP'
  'SKIP'
  'SKIP'
  'SKIP'
  'SKIP'
  '8eeb475f4987d82c1dba59392e2a9b587e1b4bfad1f54a370e9edf574107048071c777bc335e7921f8b577c557d78a048e586f1ac0f3f96a5830cffe182f1ac5'
  'f43129c8ca63f92d85cdb4e3e22f051261fcdbf4f7bfc280ba47554d9882770510bd447fc8684ceea1d39b281b742fe6f429b5a51f7de92c87a00946d3a29166'
  '4111106503b59f87a0b8dbee0dd39d81b23e11d807cd987824d8741d2720fc0d786e153b899a4a63efa6d297c7b9c6c4bbbdcbcd833961a7c947904e93dda8d9'
  'a7abe644142e3b5ff740d94eeb91c1f3d7d82ec83565bc179477da5f86b6fb4aece7176d69240d3d8657f903501ab1d8323084670b10acf60a99a015335f0402'
  '82629c6c4c3a904f7028535f1c403dc76bab3f63f21395fa1ace0cd7d8733382baf00c3b80e3243608aed82b6209fb697ed193529a1343918c37fc998a2796e6'
)
sha1sums=(
  'SKIP'
  'SKIP'
  'b179d2efb1174658483e8b41bf4ac9d2eb5de438'
  '34a67ba62097778e4695c951156bf189c2c8e016'
  'ecff5cb8b1189514c9d1d8d68eb77ac372e000c9'
  'SKIP'
  'SKIP'
  'SKIP'
  'SKIP'
  'SKIP'
  'SKIP'
)

_ant_home=/usr/share/${pkgbase}

build() {
  # HACK: get the necessary `now out of place' files
  cp ../*.jar "${srcdir}/${pkgbase}-${pkgver}/lib/optional/"
  mv ../NetRexx-3.06-GA.zip \
    "${srcdir}/${pkgbase}-${pkgver}/lib/optional/NetRexx-3.06-GA-jar"
  
  cd "${srcdir}/${pkgbase}-${pkgver}"

  # ant needs HOME to download libs to $HOME/.m2/repository
  export ANT_OPTS="-Duser.home=${srcdir}"
  # setting JAVA_HOME to boostrap a small ant binary
  export JAVA_HOME=/usr/lib/jvm/java-8-openjdk
  sh bootstrap.sh
  # HACK: || true prevents failure when ant can't fetch jai-core since
  # it moved (from maven central), despite the repository attribute for the
  # artifact in fetch.xml pointing to a valid repository..
  bootstrap/bin/ant -Ddest=optional -f fetch.xml || true

  rm lib/optional/junit-4.12.jar
  ln -s /usr/share/java/junit.jar lib/optional/junit-4.12.jar
  
  rm lib/optional/hamcrest-{core,library}-1.3.jar
  ln -s /usr/share/java/hamcrest-core.jar lib/optional/hamcrest-core-1.3.jar
  ln -s /usr/share/java/hamcrest-library.jar lib/optional/hamcrest-library-1.3.jar
  
  bootstrap/bin/ant dist
}

package_apache-ant() {
  ...
}

package_apache-ant-doc() {
  ...
}

"Ellipsis" mean that no changes were made in the respective ellipsized regions. It's an incredibly hacky solution, namely requiring "handpicking" the required artifacts to allow successful compilation and near-complete functionality. I haven't tested it to a good extent, mainly due to time constraints and lack of knowledge and experience. But from the build logs post-bootstrapping phase, it looked pretty like a successful run, if you don't mind me repeating myself.. rather tired at this point, probably only going to get a few hours of sleep. My brain thought it was worth it, at least.

There are clearly problems with this approach, considering that I wasn't capable of finding a checksum for the NetRexx archive either since the owner doesn't make it available.. I thought of shoehorning one in, creating the sum myself, but who would trust me more than the source? Doesn't make too much sense. The other checksums I either got from the sources when available, or, when it comes to the already existing files in the extra repo, I bumped the sha256 sums to sha512 instead.. which sounds kind of silly, given what I just said, but.. since those files are distributed by the maintainer, said maintainer could change them at will since he's the one providing them. Probably shouldn't to explain it.. but might as well, don't know (I'm rambling a bit at this point, sorry).

All in all, every kind of feedback and help would be dearly appreciated. I'd enjoy seeing a newer version of the tool up and available in the repos, whether it be the official ones or the AUR.

Last edited by rgcv (2018-04-06 15:59:21)

eschwartz · 2018-02-21 14:54:56

Checksums don't really prove the source is trusted, their main utility is to ensure that the file isn't corrupted or truncated during the download. Also to ensure that you build the same sources as anyone else, whether those sources are trusted out-of-band or not.

Anyway, sha512 is not really better than sha256, they both use SHA2 at the end. It might be nice to have a standard SHA3 checksumming utility in coreutils and start using that...

rgcv · 2018-02-21 22:55:38

Eschwartz wrote:

Checksums don't really prove the source is trusted, their main utility is to ensure that the file isn't corrupted or truncated during the download. Also to ensure that you build the same sources as anyone else, whether those sources are trusted out-of-band or not.

It depends, I could easily just alter the archive or the files, inject malicious code or erroneous information and alter the checksums. To an inexperient user, seeing the checksum checking passed would be one less thing to be concerned with, yet I would have managed to distribute malicious code. I do agree (like I couldn't ) that it isn't the checksums' purpose, to prove the source is trustworthy, not by itself. But using the checksums produced when the artifact was produced (presumably by the original producer) is key to ensure what's being distributed is trusted, meaning it's what the original publisher created. That's why I kept the sha1 sums of the other artifacts (other alternative would be their respective md5 sums... eww). Otherwise, I'd just use sha2 as well.

Eschwartz wrote:

Anyway, sha512 is not really better than sha256, they both use SHA2 at the end.

Hmm true.. really only thought about reducing even more the odds of collision, which isn't really that big of a deal either way. In my defense, I was incredibly tired at the time!

Eschwartz wrote:

It might be nice to have a standard SHA3 checksumming utility in coreutils and start using that...

Yes please

Thank you for the input, dearly appreciated!

Arch Linux

#1 2018-02-21 08:09:35

apache-ant 1.10.2 PKGBUILD discussion

#2 2018-02-21 14:54:56

Re: apache-ant 1.10.2 PKGBUILD discussion

#3 2018-02-21 22:55:38

Re: apache-ant 1.10.2 PKGBUILD discussion

Board footer