GNU bug report logs -
#39885
Bioconductor URI, fallback and time-machine
Previous Next
Full log
View this message in rfc822 format
Hi Ricardo,
I am late. This message landed when I was traveling for holidays. :-)
On Wed, 10 Aug 2022 at 20:25, Ricardo Wurmus <rekado <at> elephly.net> 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
This bug report was last modified 1 year and 115 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.