We check if there is a debug package found in the mirroring debug
repository and mark this as `is_debug` if found. This creates the needed
symlinks for the package pool.

Signed-off-by: Morten Linderud <morten@linderud.pw>

Luke Shumaker authored Jul 13, 2018 and Eli Schwartz committed Oct 07, 2018

The problem statement:

  checkPackageDB and checkRemovedPackageDB need bit of information on the
  package they're checking: a full list of pkgnames with that pkgbase, the
  list of pkgarches, and (for checkPackageDB only) the full version.  In
  dbscripts itself, we can get that directly from the .db files; however,
  since the test suite is checking the ability of dbscripts to edit those
  .db files, that's obviously not a good solution.

  The current solution is to get this information from the PKGBUILD...
  which we also count on dbscripts to correctly keep track of.  Wait,
  that's skipping ahead, let's back up.

  The current solution is to get this information from the PKGBUILD.  For
  checkRemovedPackageDB, that's easy; we just get it from trunk, as that's
  the most up-to-date information on the package as-it-would-have-existed
  (if that sounded a little hand-wavey, it was).  But for checkPackageDB,
  it's a little trickier, because of 2 factors working together: (1) there
  might be different versions on different repos, and (2) unlike
  checkRemovedPackageDB, checkPackageDB actually cares about pkgver.  So,
  checkPackageDB "guesses" the location in a slightly sloppy way, and is
  tagged with a "FIXME".

What todo about it?

  There are a couple of things to observe:

   - Hidden in the hand-waving in assuming that "trunk" is fine for
     checkRemovedPackageDB is the assumption that neither pkgname=() nor
     arch=() is going to change between versions.  Which is a fine
     assumption, because we don't change those things between versions in
     any of our test cases.
   - We're counting on dbscripts correctly keeping track of which PKGBUILD
     is correct for which repo... which is one of the thing's we're trying
     to test, we shouldn't be counting on it.  That's actually a bigger
     problem than the original "FIXME"!

  So, putting those things together, let's (1) take the code under test out
  of the equation, and (2) remove any suggestion that the version of the
  PKGBUILD makes a difference to pkgnames/pkgarches: Let's have both
  functions that that information from the PKGBUILDs under "fixtures/",
  rather than getting PKGBUILDs from VCS.

  That just leaves one question: How to get the correct pkgver in
  checkPackageDB?  The obvious answer is: Each test case knows what the
  version should be; add it as an argument, and adjust every testcase that
  calls it.

PKGEXT is a makepkg variable referring to a fixed filename suffix, but
we were also using it to mean a bash glob referring to candidate
filenames. This is wrong, so rename it to PKGEXTS which is more
descriptive of its purpose.

Exclude the testsuite from this change, as the testsuite actually uses
PKGEXT for its intended purpose. Fix the testsuite to consistently use
PKGEXT, as it hardcoded the file extension in several cases, and pin
its value to .pkg.tar.xz

Rather than using ugly hacks like arr[${#arr[*]}]="foo", bash 3.1 has
the += operator.

Update strings to use the same operator while we are at it.