bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ricardo Wurmus
Subject: bug#39885: Bioconductor URI, fallback and time-machine
Date: Wed, 10 Aug 2022 20:25:00 +0200
User-agent: mu4e 1.8.7; emacs 28.1

Ricardo Wurmus <rekado@elephly.net> writes:

> zimoun <zimon.toutoune@gmail.com> writes:
>
>> At the cost of more bandwidth, we could switch from url-fetch to
>> git-fetch.
>
> Let’s do it!  I’m tired of Bioconductor archive shenanigans messing with
> package availability.

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.

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

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

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

-- 
Ricardo





reply via email to

[Prev in Thread] Current Thread [Next in Thread]