[bug#50072] [PATCH WIP 4/4] upstream: Support updating git-fetch origins.

[Maxime Devos]

Sarah Morgensen schreef op di 07-09-2021 om 10:51 [-0700]:
> So there is a version number indicated elsewhere than in the tags for
> some minetest packages?  (Is this data in the package's git repo or in
> e.g. minetest repo metadata?)  That is, the minetest updater always uses
> "blessed versions" (not just random commits), such that "revision" will
> always be "0"?

The minetest importer looks at ContentDB.  E.g., for Jeija/mesecons:
https://content.minetest.net/packages/Jeija/mesecons/.  It doesn't look
at git tags at all.  It only clones the git repository to compute the hash.

Strictly speaking, ContentDB only has ‘release titles’, and not ‘version 
numbers’.
Release titles are usually version numbers or dates.  In the former case, all is
well.  In the latter case, there isn't much the importer/updater can do about 
that,
so it will use the date even though it isn't a ‘proper version number’.

Releases on ContentDB are ordered.  The importer and refresher always use the
latest release, not some random commit.  ContentDB has a mapping from releases
to their commits, which the importer and refresher uses.

So, yes, there are ‘blessed versions’.  However, due to particularities of how
minetest mods are released, revision won't always be 0, because there are
minetest mods that make a new release on ContentDB without a corresponding
version bump (e.g. minetest-ethereal, minetest-mesecons, minetest-throwing,
minetest-throwing-arrows).

> Are current minetest packages like this formatted like 'gnash' above?

About a third are formatted like 'gnash' (let ((commit ...) (revision ...)) 
...)).

Greetings,
Maxime

signature.asc
Description: This is a digitally signed message part