We should document the usual way of making a snapshot from github/gitlab/whatever forges (just list the magic links, I guess, to get a tarball of a commit). We should include: * possible instability of snapshots (and link to github changing their gzip impl before) * when it is suitable to use them (low-activity upstream project, too many patches to backport manually, and low risk from importing so many patches) * when it isn't suitable to use them (like if upstream have branched so master != next release, if there's lots of unrelated/unnecessary changes that would be pulled in by it) -- This bug is inspired by a discussion from https://github.com/gentoo/gentoo/pull/39044 and my reply at https://github.com/gentoo/gentoo/pull/39044#issuecomment-2504974430. I also recall slashbeast a while ago wanted some page like this but I can't remember if he asked for it in a bug somewhere. I'll handle this at some point, but I'm filing it both as a reminder and to ask: where should this actually go in the devmanual?
The general principle here being "not importing more patches than necessary" and also to encourage careful consideration of all changes being imported on top of the last release. This is especially important for libraries in case e.g. an accidental ABI change has snuck in on master.
fwiw I've sometime wondered the idea of having an eclass to simplify these not to have a million different MY_COMMIT variables, S redefinition, long ${MY_COMMIT} SRC_URI, and esp. also help with submodules where it gets messier possibly with an array of hashes w/ directory locations (albeit in these case it may be simpler to just host the tarballs ourselves). ...and then have such when-to-use recommendation and warnings in the eclassdocs itself. Not that I think I ever plan to go forward with that, just something I had pondered and mentioning just in case someone think it's worth looking at.
(In reply to Ionen Wolkens from comment #2) > ...and then have such when-to-use recommendation and warnings in the > eclassdocs itself. (albeit I do think it fits the devmanual)
(In reply to Ionen Wolkens from comment #2) > fwiw I've sometime wondered the idea of having an eclass to simplify [...] Exherbo has an eclass (exlib) for a bunch of these, like github.exlib: https://gitlab.exherbo.org/exherbo/arbor/-/blob/d166da254d624905b3a65819fbe33b72e18d27e2/exlibs/github.exlib. One thing that might be kind of useful is standardising the .gh.tar.gz-style suffix to help avoid collisions with distfile names. And in fact, we could even possibly recommend such a hypothetical eclass for tag use (not just commit-based snapshots). where we're not using dist tarballs. Some ebuilds in dev-ruby/ at least also already do GITHUB_USER and so on which both: a) indicates there might be a usecase for this; b) could confuse users if such a nice mechanism or even any docs on how to do this in general exist. > Not that I think I ever plan to go forward with that, just something I had > pondered and mentioning just in case someone think it's worth looking at. Worth thinking about the legacy vcs-snapshot.eclass and vcs-clean.eclass (both of which are kind of weird but I mean if anyone does want to do this, they're worth learning from and so on). I'm not sure I've ever used either of them and AFAIK -snapshot is supposed to be obsolete as-is, so saying this as a point of reference rather than "it already exists" (because it doesn't).
If we were to do such an eclass, it'd be relevant for the current discussion being had in #gentoo-rust wrt https://public-inbox.gentoo.org/gentoo-dev/20241127154707.39679-1-mytdragon@protonmail.com/ too (to avoid hardcoding knowledge about forges).
