Per-package updaters?

Per-package updaters?

[Ricardo Wurmus]

Hi Guix,

we have a couple of generic package updaters (CPAN, CRAN, Bioconductor,
Github, GNU, etc), but they don’t nearly cover all of our packages.  I
wonder if we should add one-off updaters for individual packages that
don’t fall into any of the generic classes of updaters.

Another question is how to implement them.  Would there be another
optional field in package expressions containing a Guile script to run
to determine updates for the current package?

What are your opinions on this?

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
http://elephly.net

Re: Per-package updaters?

[Ben Woodcroft]

Hi Ricardo,


On 27/12/16 01:00, Ricardo Wurmus wrote:
> Hi Guix,
>
> we have a couple of generic package updaters (CPAN, CRAN, Bioconductor,
> Github, GNU, etc), but they don’t nearly cover all of our packages.  I
> wonder if we should add one-off updaters for individual packages that
> don’t fall into any of the generic classes of updaters.
>
> Another question is how to implement them.  Would there be another
> optional field in package expressions containing a Guile script to run
> to determine updates for the current package?
>
> What are your opinions on this?
How about we piggy-back on the good work of others, by putting a 
declaration in the package definition that the package has sister 
packages in other package managers? This would involve a level of 
munging of the other packager's versions, but this seems not difficult 
for well disciplined numbering schemes.

ben

Re: Per-package updaters?

[Ludovic Courtès]

Hello Guix!

Ricardo Wurmus <rekado@elephly.net> skribis:

> we have a couple of generic package updaters (CPAN, CRAN, Bioconductor,
> Github, GNU, etc), but they don’t nearly cover all of our packages.  I
> wonder if we should add one-off updaters for individual packages that
> don’t fall into any of the generic classes of updaters.
>
> Another question is how to implement them.  Would there be another
> optional field in package expressions containing a Guile script to run
> to determine updates for the current package?
>
> What are your opinions on this?

Currently we have ways to provide the generic updates with additional
hints.  For instance, we can provide hints to the ‘gnu’ updater:

  (define-public guile-next
    (package (inherit guile-2.0)
      (name "guile-next")
      ;; …
      (properties '((upstream-name . "guile")
                    (ftp-server . "alpha.gnu.org")
                    (ftp-directory . "/gnu/guile")))))

I suspect that one-off updaters would most likely use methods very
close to the existing updaters.  For instance, we could have a generic
FTP updater that would apply to all packages available on FTP; or we
could have a generic updater that crawls HTML pages for release numbers
and such things.  Then we would have optional properties in packages to
specify which method to use, or something along these lines.

WDYT?  Do you have examples in mind?

Cheers,
Ludo’.

Re: Per-package updaters?

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 2091 bytes --]

On Sat, Dec 31, 2016 at 01:29:15AM +0100, Ludovic Courtès wrote:
> Hello Guix!
> 
> Ricardo Wurmus <rekado@elephly.net> skribis:
> 
> > we have a couple of generic package updaters (CPAN, CRAN, Bioconductor,
> > Github, GNU, etc), but they don’t nearly cover all of our packages.  I
> > wonder if we should add one-off updaters for individual packages that
> > don’t fall into any of the generic classes of updaters.
> >
> > Another question is how to implement them.  Would there be another
> > optional field in package expressions containing a Guile script to run
> > to determine updates for the current package?
> >
> > What are your opinions on this?
> 
> Currently we have ways to provide the generic updates with additional
> hints.  For instance, we can provide hints to the ‘gnu’ updater:
> 
>   (define-public guile-next
>     (package (inherit guile-2.0)
>       (name "guile-next")
>       ;; …
>       (properties '((upstream-name . "guile")
>                     (ftp-server . "alpha.gnu.org")
>                     (ftp-directory . "/gnu/guile")))))
> 
> I suspect that one-off updaters would most likely use methods very
> close to the existing updaters.  For instance, we could have a generic
> FTP updater that would apply to all packages available on FTP; or we
> could have a generic updater that crawls HTML pages for release numbers
> and such things.  Then we would have optional properties in packages to
> specify which method to use, or something along these lines.
> 
> WDYT?  Do you have examples in mind?
> 

Sourceforge has an rss feed for each project they host. For example, for
libcddb: https://sourceforge.net/projects/libcddb/rss

Another example is Debian, which has a "watch file" that does something™,
for example cairo's:
https://sources.debian.net/src/cairo/1.14.8-1/debian/watch/

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Per-package updaters?

[Ludovic Courtès]

Efraim Flashner <efraim@flashner.co.il> skribis:

> On Sat, Dec 31, 2016 at 01:29:15AM +0100, Ludovic Courtès wrote:
>> Hello Guix!
>> 
>> Ricardo Wurmus <rekado@elephly.net> skribis:
>> 
>> > we have a couple of generic package updaters (CPAN, CRAN, Bioconductor,
>> > Github, GNU, etc), but they don’t nearly cover all of our packages.  I
>> > wonder if we should add one-off updaters for individual packages that
>> > don’t fall into any of the generic classes of updaters.
>> >
>> > Another question is how to implement them.  Would there be another
>> > optional field in package expressions containing a Guile script to run
>> > to determine updates for the current package?
>> >
>> > What are your opinions on this?
>> 
>> Currently we have ways to provide the generic updates with additional
>> hints.  For instance, we can provide hints to the ‘gnu’ updater:
>> 
>>   (define-public guile-next
>>     (package (inherit guile-2.0)
>>       (name "guile-next")
>>       ;; …
>>       (properties '((upstream-name . "guile")
>>                     (ftp-server . "alpha.gnu.org")
>>                     (ftp-directory . "/gnu/guile")))))
>> 
>> I suspect that one-off updaters would most likely use methods very
>> close to the existing updaters.  For instance, we could have a generic
>> FTP updater that would apply to all packages available on FTP; or we
>> could have a generic updater that crawls HTML pages for release numbers
>> and such things.  Then we would have optional properties in packages to
>> specify which method to use, or something along these lines.
>> 
>> WDYT?  Do you have examples in mind?
>> 
>
> Sourceforge has an rss feed for each project they host. For example, for
> libcddb: https://sourceforge.net/projects/libcddb/rss

Looks like something we could use in a generic SourceForge updater.

> Another example is Debian, which has a "watch file" that does something™,
> for example cairo's:
> https://sources.debian.net/src/cairo/1.14.8-1/debian/watch/

Yes, that’s pretty nice.

Ludo’.