Re: gnumaint changes

[Ludovic Courtès]

Hello,

Mike Gerwitz <address@hidden> skribis:

>> It’d be nice if synopses and descriptions in the Womb could contain
>> Texinfo markup.
>>
>> In fact, perhaps it’d make sense to reverse the roles, i.e., have the
>> Womb take (some of its) descriptions from Guix?
>
> `blub' in pkgblurbs (which is what `official-description' uses) is
> provided by package authors after they've been dubbed by rms.  That is
> in turn used on gnu.org.  Consequently, I think it's best to have such
> blurbs maintained independently of guix.

I see, that makes sense.

> What sort of Texinfo markup are you looking for, and are we talking
> about the same field?  What field does guix use for the synopsis?
> Everything in rec/gnupackages.rec is handled by us at maintainers@, so
> we can do whatever we want there.

For packages we occasionally use Texinfo markup, typically ornaments
like @code or @itemize bullet lists.  Not every synopsis/description
needs it, but it’s nice to be able to use it.

> Do you have a couple examples of what you think would be beneficial to
> pull form Guix?  I'm certainly open to the idea where it makes sense;
> there's no sense in us duplicating effort within GNU unnecessarily.

I realize that Guix doesn’t have all GNU packages yet so in fact there’s
not so much to pull from at this point.  I was suspecting blurbs are
likely to be more up-to-date in Guix, but that’s very subjective, I
don’t know if this is the case.

> I'm also working on automating parts of our recordkeeping: in the next
> few weeks, Womb will have up-to-date version information automatically
> pulled from info-gnu release announcements; the FTP server; and a couple
> websites where necessary, though I'll be manually committing it for the
> first few months to verify that it is all working properly.  So Guix
> might also be able to depend on rec/gnupackages.rec for checking for new
> releases as well, since unfortunately GNU doesn't mandate the use of the
> FTP server, or even info-gnu (so releases are all over the place).

The (guix gnu-maintenance) modules are tools to retrieve the latest
version of a GNU package by traversing its ftp.gnu.org (or similar)
directory.  That’s something you might find useful.  Here’s an example:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,use(gnu packages gcc)
scheme@(guile-user)> ,use(guix upstream)
scheme@(guile-user)> (package-latest-release gcc (force %updaters))
$4 = #<<upstream-source> package: "gcc" version: "8.1.0" urls: 
("mirror://gnu/gcc/gcc-8.1.0/gcc-8.1.0.tar.xz" 
"mirror://gnu/gcc/gcc-8.1.0/gcc-8.1.0.tar.gz") signature-urls: 
("mirror://gnu/gcc/gcc-8.1.0/gcc-8.1.0.tar.xz.sig" 
"mirror://gnu/gcc/gcc-8.1.0/gcc-8.1.0.tar.gz.sig")>
--8<---------------cut here---------------end--------------->8---

Or simply:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,use(guix gnu-maintenance)
scheme@(guile-user)> (latest-release "emacs")
$5 = #<<upstream-source> package: "emacs" version: "26.1" urls: 
("ftp://ftp.gnu.org/gnu/emacs/emacs-26.1.tar.xz"; 
"ftp://ftp.gnu.org/gnu/emacs/emacs-26.1.tar.gz";) signature-urls: 
("ftp://ftp.gnu.org/gnu/emacs/emacs-26.1.tar.xz.sig"; 
"ftp://ftp.gnu.org/gnu/emacs/emacs-26.1.tar.gz.sig";)>
--8<---------------cut here---------------end--------------->8---

This relies primarily on <https://ftp.gnu.org/find.txt.gz>.

Packages not hosted on gnu.org are typically annotated with the download
URL such that the update-checking code does the right thing.

Thanks,
Ludo’.