It was passing the display text to the sort function, not the
enum value, so only worked by accident. Refactor/rename things a
bit to make this more clear.
Also give the unknown/unprocessed state a higher priority, so it
shows up before the finished builds. Same for manual builds, since
they require user action.
It was sorted by change date before, which does not say when
something was merged but when it was commited.
At least for me, I want to see if there are any problems and what is
currently building when looking at the queue, and only then what already
is there. Might be different for other users.
Sort by the status priority instead. The priority is the same one used to
decide the most important build status to show in the list for the
different build types.
We keep package names unique, and if for some reason they wouldn't be
we show both packages on that page then.
Let's not add a query param to every URL for such an edge case.
We guarded in various places by whether vulns exist and then used
worst_vulnerability to select a color, but in case all are ignored
worst_vulnerability is None and things fail.
Introduce all_vulnerabilities/active_vulnerabilities/worst_active_vulnerability
properties and make sure that worst_active_vulnerability is always guarded
properly.
It'a a list of CVE IDs or GHSA IDs which whould be ignored.
In lists we still show them, but at the end and with strike through.
For picking the worst for the tooltip button color we ignore them.
On the security page, of all are ignored, the package is skipped.
In case the version is an empty string it is considered newer by pacman
than for example "r123".
Instead make it optional and handle the None version everywhere.
Fixes#68
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.
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
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.
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
