When parsing the SRCINFO we only get out the sub packages and the
package fields override the base fields, but the base description
has some vlaue on its own, as it is a description for all contained
packages.
Store the base description away and when fetching the description
for the pacman DB package we look up the description from the SRCINFO
base package if possible.
The onyl downside here is that they come from different sources, so
might be out of sync, but still better then before I guess.
Since we now have a concept of main and fallback versions we shouldn't
compare the repo version to all versions, but ignore the fallback ones
if there are others.
This allows us to specifiy multiple URLs for each project in addition
to the homepage that is defined by the PKGBUILD.
This is similar to what Python packages can do, which then gets
exposed on pypi. But while they allow free form text we specify
a fixed set with a specific purpose, so we can pontentially re-use them
in the future, and also to make it more clear what we expect them to
point to.
AUR contains dev versions we don't care about and cywin
sometimes uses a different versioning scheme.
Only if there is no matching Arch package consider the other ones
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.
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
