[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The Nixpkgs Monitor
From: |
Ludovic Courtès |
Subject: |
Re: The Nixpkgs Monitor |
Date: |
Sat, 18 Jan 2014 16:35:14 +0100 |
User-agent: |
Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux) |
Andreas Enge <address@hidden> skribis:
> On Tue, Jan 14, 2014 at 02:42:47PM +0100, Ludovic Courtès wrote:
>> A great initiative that we could get inspiration from: the Nixpkgs
>> Monitor scans packages for updates à la ‘guix refresh’ (but not limited
>> to GNU packages), and also for CVEs.
>
> What is the limitation on scanning for updates only for GNU packages?
The (guix gnu-maintenance) modules embeds knowledge about GNU practices
(use of ftp.gnu.org), plus knowledge about exceptions (such as GNU
packages hosted elsewhere.)
To be generalized, that knowledge would typically need to be embedded in
package definitions. A new field would be used to embed a description
of what method to use (currently we only do FTP scans, but we’d at least
need something HTTP-based), and what base URI to search.
Something like that:
(define gcc-4.7
(package
...
(updates (upstream-updates
(method ftp-scan)
(uri-pattern
'("ftp://ftp.gnu.org/gnu/gcc/4.7/gcc-" version
".tar.gz"))))))
> Could the same logic not be used for other packages that do not contain part
> of the package version in their download uris, and maybe even others?
Perhaps we could deduce URI patterns in the best case from the origin’s
URI. But it’s not clear that it would always work.
And what do we do for URIs in http:// or mirror://?
Debian has a tool called ‘uscan’. I wonder if Nixpkgs Monitor uses
that.
Thanks,
Ludo’.