GNU bug report logs - #52977
[PATCH 0/6] Update some minetest packages

Previous Next

Full log

Message #40 received at 52977 <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>, Ludovic
 Courtès <ludo <at> gnu.org>
Cc: 52977 <at> debbugs.gnu.org
Subject: Re: bug#52977: [PATCH 0/6] Update some minetest packages
Date: Thu, 06 Jan 2022 09:33:53 +0000

[Message part 1 (text/plain, inline)]

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.

* 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).

  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.

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.

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.

Greetings,
Maxime.

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.