[bug#52977] [PATCH 0/6] Update some minetest packages

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Hi,

Am Donnerstag, dem 06.01.2022 um 09:33 +0000 schrieb Maxime Devos:
> Hi,
> 
> Liliana Marie Prikler schreef op do 06-01-2022 om 01:52 [+0100]:
> > > [...]
> > If I recall correctly, this was also a point of debate in the initial
> > series that added the importer.  Can we establish an
> > ordering/heuristic here?  E.g. "if we have git tags use those,
> > otherwise use contentdb", "always use contentdb" or "always use
> > whatever was edited most recently"?
> 
> Keep in mind that the minetest importer doesn't know about git tag
> -- the only interaction it has with git is cloning repositories
> and checking out commits by the commit id provided by ContentDB.
> I'm assuming you're referring to the generic-git updater here,
> or a hypothetical minetest updater that has been modified to
> interact with git tags.
Ahh, sure, but imho it could try to make a best effort guess.  E.g. if
git tags are named like Minetest releases and exist in equal count,
assume a mapping from one to the other.  However if I recall correctly
there was a ContentDB policy to only tag once, which makes the mapping
from ContentDB version to git commit unique.  Do I remember correctly?

> * Problem with using git tags: git tags sometimes disappear.
>   E.g., in minetest-ethereal, there's currently a tag
>   2021-04-06 and 2021-09-23, but there's no tag for 2021-07-28
>   (the version currently in guix).
> 
>   This could be resolved by including the commit instead of the
>   tag in the package definition, and still searching for the git tag,
>   but as I understand it, there have been some objections to
>   including the commit in the package definition
> (https://lists.gnu.org/archive/html/guix-devel/2021-12/msg00259.html).
Thanks for linking my thread :)

I do cite minetest.scm as an exception there, since your comments make
very clear what you're doing and why.  However, my actual intent is
blown way out of proportion, which has led to a lot of confusion on all
sides and a rather long discussion.

To clarify it here, I am trying to avoid the following pattern:

  (package 
    (name "hello")
    (version "1.0")
    (source 
      (origin 
        (method git-fetch)
        (uri (git-reference
               (url some-url)
               (commit "abcdef...")))
        [...]))
    [...])

while encouraging both

  (package 
    (name "hello")
    (version "1.0")
    (source 
      (origin 
        (method git-fetch)
        (uri (git-reference
               (url some-url)
               (commit (version->git-tag version))))
        [...]))
    [...])

and

  (package 
    (name "hello")
    (version (git-version "1.0" revision commit))
    (source 
      (origin 
        (method git-fetch)
        (uri (git-reference
               (url some-url)
               (commit commit)))
        [...]))
    [...])

In the latter, revision and commit are let-bound as per Guix'
standards.  Now if you say "minetest mod packages are generally
unreliable, git-version everywhere", that is completely fine by me.

>   Even then, there's another problem: sometimes releases are made
>   without a corresponding git tag.  E.g., on ContentDB there's a
>   version 2022-01-05 but there's no 2022-01-05 tag in the git
>   repository.
> 
>   That could be resolved by ‘always use contentdb for minetest
>   packages’ or ‘always use whatever was edited most recently’.
> 
> * Problem with ‘whatever was edited most recently’: AFAIK git tags
>   don't carry that information. Though the commit time/modification
>   time in the commit it points to might be a decent approximation
>   in practice.
> 
>   ContentDB has some information on when a release was released
>   (release_date, see https://content.minetest.net/help/api/).
> 
>   I suppose this could work, though there's a slight problem:
> 
>   The version scheme in guix would occassionally switch between x.y.z
>   and YYYY-MM-DD, which would confuse the ‘these packages have been
>   upgraded’ logic.
Does ContentDB always use CalVer or are the repo owners in control of
the tags?  If there's a SemVer/CalVer conflict, I would say doing 
(latest-semver)-(calver)-commit would probably be acceptable.  At least
I hope none of these mods release twice daily.

> I suppose the best option would be to always use the version from
> ContentDB (*), because the exact versioning scheme used doesn't
> matter much, as long as it remains consistent over time, and just
> using ContentDB is convenient.
> 
> (*) Unless it isn't on ContentDB of course, though all minetest
> packages currently in Guix are on ContentDB.
If a package was used outside of ContentDB, that's not ContentDB's
requirement, is it?  Now perhaps there is an issue if the contentdb
updater relies on the minetest-mod-build-system being used to determine
that its suitable, rather than something else.

> Additionally, if the forum versions / git tags / contentdb releases
> are inconsistent (e.g. the forum and git tags are x.y.z and the
> releases are YYYY-MM-DD), we could inform upstream that guix uses the
> release titles because otherwise things become complicated for guix,
> so if upstream doesn't want that, they need to use x.y.z in their
> release titles as well
> 
> Does that seem reasonable to you? I could write a patch to that
> effect.
Poking upstream maintainers sounds fun, but before making a hard
decisions, perhaps we should reach out to them and ask what they
consider the most reliable.  If it's a wild mess, we could also use
package-properties with an assumed default of "release title = git tag
= forum post", e.g. (upstream-versioning . forum-post), (upstream-
versioning . contentdb) and (upstream-versioning . git-version) to
indicate who's right in case of a mismatch.

WDYT?