Hi Ricardo, 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: --8<---------------cut here---------------start------------->8--- $ 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() --8<---------------cut here---------------end--------------->8--- Do we follow ’master’? Is it a mirror of what Bioconductor names their 3.14 release? My guess was that RELEASE_3_14 mirrors their 3.14 release. >> 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. > 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 question is: do we have to include the migration in the updater? Or do we do the migration by custom scripts? 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. Cheers, simon
