Hi, (Replying to a 1.5-year-old message…)
Ricardo Wurmus <rek...@elephly.net> skribis: > 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. Alternatively, how about writing a custom one-shot tool to change the ‘source’ field of all the Bioconductor packages to ‘git-fetch’? It may be easier than adjusting (guix upstream) to cater to this probably unusual case. > - 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. OK, sounds acceptable. > - 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. Maybe we can build upon Maxime’s patch at <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. > > - 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. I don’t think it happened but it’d still be nice. :-) Thanks, Ludo’.
