To make clear that this info depends on other packages, and since
those lists can be quite long it's best to have all the other package
information before it.
Up until now we would show a list of packages and providing
packages. That's confusing when you don't scroll down and not
really obvious.
Instead if it's a virtual package show a simple page listing
the providing packages.
And in case a package of that name exists, show the other packages
providing the same name inline ("Provided By")
Instead just use the srcinfo and the packages. In case a package moves between bases
it would look up the old srcpkg and display outdated names.
This is a leftover from when we had no srcinfo data.
In case a package that is to be built is also replaced we would take
the dependencies of the replacement instead of the real one.
While this usually never happens, as the resulting package will be removed
on upgrades, it is wrong to do so. Don't resolve the package like
pacman would and just use them as is instead
Both builders will upload the complete build status when they run,
but up until now we only read the one from the main autobuild repo.
This meant that if the arm runner was building something without
the main autobuild running the website wouldn't notice and always
show the out of date state until the next scheduled run.
This now loads both and takes the newest according to the last-modified header
send by github. To keep local caching working during development we
store the last-modified as the cache file mtime.
This adds the following things:
* the mapping data is now sourced from the package repositories
* cygwin mapping works too (for example see "msys2-runtime")
* packages can be marked internal so they are never linked
to arch or cygwin (for example see "base")
Instead of doing regex and using the extracted package name, just
use the real pkgbase everywhere. This might mean more mappings are needed,
but it's more clear what it changes.
The next step is to move the mapping into the packaging repos.
This is conceptionally similar to a pkgbase, but for groups.
Something like this doesn't really exist on the PKGBUILD level,
but end users can't really work with pkgbase with pacman either,
so for them that doesn't matter.
It still gives the end user the same structure as with packages,
there is a base thing that has multiple instances for each environment,
and searching might be a bit easier.
The UX could be improved, but the basics are there at least.
Fixes#47
base-devel is the set of packages makepkg potentially needs,
so always depend on it so things get (1) installed and (2)
built first.
This potentially leads to more cycles, but we can try to clean
up base-devel a bit more.. or just deal with them manually when needed.
Previously only packages which could be added to the repo were green,
now all that successfully built are green. Makes it easier to see
where things are stuck or where manual intervention is needed.
