bug#39885: Bioconductor URI, fallback and time-machine

["Ludovic Courtès" <ludovic.courtes@inria.fr>]

Hi,

(Replying to a 1.5-year-old message…)

Ricardo Wurmus <rekado@elephly.net> skribis:

> I have finally taken the time to review this and implement a first draft
> of a change to the bioconductor importer and updater.
>
> There are some limitations:
>
> - we cannot use the updater to go from “url-fetch” to “git-fetch”.
>   That’s because “package-update” in (guix upstream) decides whether to
>   use package-update/url-fetch or package-update/git-fetch based on the
>   *current* package value’s origin fetch procedure.  For the switch we
>   can hack around this (adding an exception for bioconductor packages),
>   but there is no pretty way to do this in a generic fashion that could
>   be committed.
>
>   Perhaps we could operate on the url included in the <upstream-source>
>   instead of looking at the *current* package value.  We’re only
>   accessing “package” once in the url-fetch case, so maybe we can work
>   around this problem.

Alternatively, how about writing a custom one-shot tool to change the
‘source’ field of all the Bioconductor packages to ‘git-fetch’?

It may be easier than adjusting (guix upstream) to cater to this
probably unusual case.

> - the repositories at https://git.bioconductor.org/package/NAME do not
>   tag package versions.  The only method of organization is branches
>   that are named after *Bioconductor releases* (not package releases),
>   e.g. RELEASE_3_15.  We can only determine the package version by
>   reading its DESCRIPTION file or by looking up the version index for
>   all Bioconductor packages (we do that already).  This means that there
>   could be different commits for the same package version in the same
>   release branch — so we have to include the commit hash and a revision
>   counter in the version string.

OK, sounds acceptable.

> - the updater doesn’t work on version expressions like (git-version
>   "1.12" revision commit).  It expects to be able to replace literal
>   strings.  Because of that my changes let the importer generate a
>   string literal such as "1.12-0.cafebab" without a let-bound commit
>   string.

Maybe we can build upon Maxime’s patch at
<https://issues.guix.gnu.org/53144#13>?

> - “experiment” or “data” packages are not kept in Git.  They only exist
>   as volatile tarballs that will be overwritten.  Thankfully, they don’t
>   change all that often, so they have a good chance of making it into
>   our archives.
>
> - the above exception means that we need to litter the importer and
>   updater code with extra checks.
>
> With all these notes out of the way I’ll prepare a series of patches
> next.

I don’t think it happened but it’d still be nice.  :-)

Thanks,
Ludo’.