Hello,
Mike Gerwitz <m...@gnu.org> 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’.
