guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Updater coverage


From: Ludovic Courtès
Subject: Updater coverage
Date: Wed, 30 Nov 2016 18:09:22 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Hi Guix!

I’ve pushed a few improvements to ‘guix refresh’ so we have a clearer
view of package coverage.

A first one is to report the lack of an updater for packages specified
on the command line so one can tell the difference between “no updater”
and “up-to-date”:

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix refresh libreoffice
gnu/packages/libreoffice.scm:711:2: warning: no updater for libreoffice
--8<---------------cut here---------------end--------------->8---

Another one is to show the actual package coverage:

--8<---------------cut here---------------start------------->8---
$ ./pre-inst-env guix refresh --list-updaters 
Available updaters:

  - gnu: Updater for GNU packages (6.3% coverage)
  - gnome: Updater for GNOME packages (3.3% coverage)
  - kde: Updater for KDE packages (1.5% coverage)
  - xorg: Updater for X.org packages (3.9% coverage)
  - kernel.org: Updater for packages hosted on kernel.org (.6% coverage)
  - elpa: Updater for ELPA packages (.2% coverage)
  - cran: Updater for CRAN packages (3.6% coverage)
  - bioconductor: Updater for Bioconductor packages (1.1% coverage)
  - hackage: Updater for Hackage packages (5.9% coverage)
  - pypi: Updater for PyPI packages (3.9% coverage)
  - gem: Updater for RubyGem packages (3.1% coverage)
  - github: Updater for GitHub packages (8.6% coverage)

42.1% of the packages are covered by these updaters.
--8<---------------cut here---------------end--------------->8---

42% is not a lot.  We could probably do 60% or so, notably by adding
updaters for CPAN, SourceForge, and Savannah.

I added the kernel.org updater and then realized that it only helps with
0.6% of the packages…

Next we should aim for more automation: automatic update of the list of
dependencies when possible (as Ricardo suggested), automatic build,
commit with the right log upon success and to the right branch based on
the number of rebuilds and/or submission as a patch.  This is far from
trivial but that should be our horizon.

Thoughts?

Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]