zimoun <zimon.touto...@gmail.com> writes:
> On Thu, 14 Apr 2022 at 13:43, Ricardo Wurmus <rek...@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