all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Per-package updaters?
@ 2016-12-26 15:00 Ricardo Wurmus
  2016-12-26 23:48 ` Ben Woodcroft
  2016-12-31  0:29 ` Ludovic Courtès
  0 siblings, 2 replies; 5+ messages in thread
From: Ricardo Wurmus @ 2016-12-26 15:00 UTC (permalink / raw)
  To: guix-devel@gnu.org

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Per-package updaters?
  2016-12-26 15:00 Per-package updaters? Ricardo Wurmus
@ 2016-12-26 23:48 ` Ben Woodcroft
  2016-12-31  0:29 ` Ludovic Courtès
  1 sibling, 0 replies; 5+ messages in thread
From: Ben Woodcroft @ 2016-12-26 23:48 UTC (permalink / raw)
  To: Ricardo Wurmus, guix-devel@gnu.org

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Per-package updaters?
  2016-12-26 15:00 Per-package updaters? Ricardo Wurmus
  2016-12-26 23:48 ` Ben Woodcroft
@ 2016-12-31  0:29 ` Ludovic Courtès
  2017-01-03  9:30   ` Efraim Flashner
  1 sibling, 1 reply; 5+ messages in thread
From: Ludovic Courtès @ 2016-12-31  0:29 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: guix-devel@gnu.org

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’.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Per-package updaters?
  2016-12-31  0:29 ` Ludovic Courtès
@ 2017-01-03  9:30   ` Efraim Flashner
  2017-01-03 13:17     ` Ludovic Courtès
  0 siblings, 1 reply; 5+ messages in thread
From: Efraim Flashner @ 2017-01-03  9:30 UTC (permalink / raw)
  To: Ludovic Courtès; +Cc: guix-devel@gnu.org

[-- 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 --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Per-package updaters?
  2017-01-03  9:30   ` Efraim Flashner
@ 2017-01-03 13:17     ` Ludovic Courtès
  0 siblings, 0 replies; 5+ messages in thread
From: Ludovic Courtès @ 2017-01-03 13:17 UTC (permalink / raw)
  To: Efraim Flashner; +Cc: guix-devel@gnu.org

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’.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2017-01-03 13:17 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-12-26 15:00 Per-package updaters? Ricardo Wurmus
2016-12-26 23:48 ` Ben Woodcroft
2016-12-31  0:29 ` Ludovic Courtès
2017-01-03  9:30   ` Efraim Flashner
2017-01-03 13:17     ` Ludovic Courtès

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.