bug#54787: importer Bioconductor: no tarball, only Git

[Ricardo Wurmus <rekado@elephly.net>]

zimoun <zimon.toutoune@gmail.com> writes:

> On Thu, 14 Apr 2022 at 13:43, Ricardo Wurmus <rekado@elephly.net> wrote:
>
>> We probably should *not* use RELEASE_3_14 (or whatever) as the commit,
>> though, because that is a moving target.  We need to resolve to the
>> actual commit and use its hash.
>>
>> I wonder how the updater would need to be changed.  It would need to
>> know about the release branch and look for new commits in that branch
>> only.
>
> To be honest, I have not checked the Bioconductor documentation about
> their Git repo structure.  What I see is:
>
> $ git clone https://git.bioconductor.org/packages/CHETAH
> $ cd CHETAH
> $ git branch -av
> * master                      5d5f5df [origin/master] Pass serialized S4 instances thru updateObject()
>   remotes/origin/HEAD         -> origin/master
>   remotes/origin/RELEASE_3_10 063de2d bump x.y.z version to even y prior to creation of RELEASE_3_10 branch
>   remotes/origin/RELEASE_3_11 701ca7f bump x.y.z version to even y prior to creation of RELEASE_3_11 branch
>   remotes/origin/RELEASE_3_12 cd3dd78 bump x.y.z version to even y prior to creation of RELEASE_3_12 branch
>   remotes/origin/RELEASE_3_13 1eacdb8 bump x.y.z version to even y prior to creation of RELEASE_3_13 branch
>   remotes/origin/RELEASE_3_14 03295c9 bump x.y.z version to even y prior to creation of RELEASE_3_14 branch
>   remotes/origin/RELEASE_3_9  22b53f2 version bump
>   remotes/origin/master       5d5f5df Pass serialized S4 instances thru updateObject()
>
>
> Do we follow ’master’?  Is it a mirror of what Bioconductor names their
> 3.14 release?

We should not follow “master”.  That’s the development branch.  We
should follow the current release branch.

> My guess was that RELEASE_3_14 mirrors their 3.14 release.

Correct.

>>> Well, I am also in favor to break the API and move %bioconductor-version
>>> and %bioconductor-url to (guix build-system r).  WDYT?  It would
>>> simplify some things (#36805 and #39885), I guess.
>>
>> We tried this before and we couldn’t do this because of a circular
>> reference.
>
> Well, I have something that works.  So I do not know if this circular
> reference is still there.

If “make as-derivation” does not fail it is probably okay.

>> That’s because the importer doesn’t let us specify a different branch.
>> We should add that, but it’s strictly separate from the migration we’re
>> about to embark on.
>
> I am not familiar with the updater (guix refresh -u).  My plan is:
>
>  1. Add bioconductor-git-reference
>  2. Adapt the bioconductor importer.
>  3. Updater?

The updater is closely connected to the importer.  It just needs to be
told how it can find new releases.

> The question is: do we have to include the migration in the updater?  Or
> do we do the migration by custom scripts?

We can do the migration manually.  But if we end up with a broken
updater I won’t be able to update Bioconductor packages in bulk; that
would be a serious problem for future maintenance.

> Note that, because we do not support shallow clones, the complete
> sources will be a bit bigger; since they contain all the Bioconductor
> history of all the packages.

Doesn’t Guile-Git support shallow clones?  In any case, this should not
be an obstacle for us.  Ensuring long-term reproducibility is more
important than space savings.

-- 
Ricardo