Add them all as separate rows with the URO, instead of inline with just the label.
Seeing the URL has some value, if the URL is for github you already
know what to expect before going there etc.
It's only relevant for schema changes and downgrades and only
useful for deciding if a version is newer, which website users
rarely need to do.
Let's just hide it by default. It's still part of the package file name
if really needed.
The previous words sounds like user want to introduce an issue.
Also FYI, bugs are any insect or insectlike invertebrate. Those
are not related to programming or computer and live in wild :-)
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.
previously the src build types were merged with the repos
they were connected with, so msys-src with msys etc.
Usually when filtering for "mingw64" one doesn't want to know the
build status of "mingw-src", so skip all that and just leak the
build types to the frontend as is.
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.
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
The change in bb4b996726 broke the package details view since
it defaults the repo filter to mingw64, so clang64 links are broken now.
This now only applies the default for the list.
To avoid mixing things up in the future split up the endpoint logic.
Fixes#55
