Just have one fiber at the moment, but this will enable using fibers for
parallelism in the future.
Fibers seemed to cause problems with the logging setup, which was a bit odd in
the first place. So move logging to the parent process which is better anyway.
And create a proper git_branches table in the process.
I'm hoping this will help with slow deletions from the
package_derivations_by_guix_revision_range table in the case where there are
lots of branches, since it'll separate the data for one branch from another.
These migrations will remove the existing data, so
rebuild-package-derivations-table will currently need manually running to
regenerate it.
Start at least looking for package replacements, and storing the
details (particularly the derivation). I'm looking at doing this so that build
servers using the Guix Data Service can build these derivations.
And use it for the systems in the derivations and package derivations tables.
The primary motivation here is to allow quickly working out what systems the
database contains, and having a small table with just the right data seems a
good way to do that.
This might be useful for working out when a non-master branch contains a newer
version of a package, or someone has sent in a patch for a newer version
already.
Previously, the name wasn't taken in to account when filtering results, so a
search like "git-annex" wouldn't find the git-annex package, since it's
synopsis or description doesn't include the name.
Filtering on the name made the queries much slower, so to address that, the
filtering by revision is moved to a separate part of the CTE, which means
PostgreSQL filters down the rows by quite a lot before it begins filtering by
name.
Also, add in a variant of the query without dashes (-) because that helps with
searches like ruby-engine.
From the normalized one, to the one actually contained within glibc. Recent
versions of glibc also contain symlinks linking the normalized codeset to the
locales with the .UTF-8 ending, but older ones do not.
Maybe handling codeset normalisation for queries would be good, but the locale
values ending in .UTF-8 are more compatible and allow the code to be
simplified. For querying, maybe there should be a locales table which handles
different representations.
This recent change simply didn't work, the ordering was bad and the window
function wasn't properly defined. It now should hopefully work, although
there's an interesting case where different versions are available for
different systems/targets, which isn't handled particularly well.
Rather than having two big tables looking at the history, just use the
derivations table as it has all the information.
This will allow deleting the package_versions_by_guix_revision_range table
which should help save time when importing revisions, and reduce the size of
the database.
Previously, if you searched for packages like Ruby or Guile, the actual Ruby
and Guile packages would be low in the rankings, as the terms Ruby or Guile
don't appear much in the descriptions.
Therefore, change the ordering to make these exact matches appear higher up.
Add tests around the package module, extract out the use of the
inferior-package record assessors so that they aren't part of the tests, and
switch across the package-metadata module to use
insert-missing-data-and-return-all-ids.
A large proportion of these changes relate to changing the way
packages relate to derivations. Previously, a package at a given
revision had a single derivation. This was OK, but didn't account for
multiple architectures.
Therefore, these changes mean that a package has multiple derivations,
depending on the system of the derivation, and the target system.
There are multiple changes, small and large to the web interface as
well. More pages link to each other, and the visual display has been
improved somewhat.
This is a service designed to provide information about Guix. At the
moment, this initial prototype gathers up information about packages,
the associated metadata and derivations.
The initial primary use case is to compare two different revisions of
Guix, detecting which packages are new, no longer present, updated or
otherwise different.
It's based on the Mumi project.
[1]: https://git.elephly.net/software/mumi.git
Christopher Baines
Danjela Lura