Hi Ricardo, I am late. This message landed when I was traveling for holidays. :-)
On Wed, 10 Aug 2022 at 20:25, Ricardo Wurmus <[email protected]> wrote: > - 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. It appears to me acceptable to have an exception. Or even to do it just once as a big replacement of Bioconductor packages. > - 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. This is the most annoying part. Indeed, when I check out some Bioconductor Git repositories, I am always confused by their Git structure. >From my understanding, the tarball you fetch from bioconductor.org has the same content than the commit tagged “Bioconductor release” (RELEASE_X_Y). The content of the upstream release can mismatch the content of the Bioconductor tarball release. I do not know how it would be complicated or inaccurate to consider the package version from the Bioconductor index and assign this version to the commit tagged RELEASE_X_Y. This commit would appear in the Guix package definition though. Or maybe we transparently could RELEASE_X_Y to determine this commit. > - 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. Maxime pointed patch#53144 [1] but I have not looked at it yet. 1: <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. That’s an interesting question for Disarchive and Software Heritage. Cheers, simon
