From: Maxime Devos <maximedevos@telenet.be>
To: "Liliana Marie Prikler" <liliana.prikler@gmail.com>,
"Ludovic Courtès" <ludo@gnu.org>
Cc: 52977@debbugs.gnu.org
Subject: [bug#52977] [PATCH 0/6] Update some minetest packages
Date: Thu, 06 Jan 2022 09:33:53 +0000 [thread overview]
Message-ID: <e95947b2ae0fe183c5dc1e5699998a56d06fd61d.camel@telenet.be> (raw)
In-Reply-To: <4dcbff837011d55f31b2514364c88e9011760a69.camel@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3030 bytes --]
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.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
next prev parent reply other threads:[~2022-01-06 9:36 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-03 13:45 [bug#52977] [PATCH 0/6] Update some minetest packages Maxime Devos
2022-01-03 15:22 ` [bug#52977] [PATCH 1/6] gnu: minetest-basic-materials: Update to 2021-12-26 Maxime Devos
2022-01-03 15:22 ` [bug#52977] [PATCH 2/6] gnu: minetest-homedecor-modpack: " Maxime Devos
2022-01-03 15:22 ` [bug#52977] [PATCH 3/6] gnu: minetest-mobs: Update to 2021-12-12 Maxime Devos
2022-01-03 15:22 ` [bug#52977] [PATCH 4/6] gnu: minetest-mobs-animal: Update to 2021-11-14 Maxime Devos
2022-01-03 15:22 ` [bug#52977] [PATCH 5/6] gnu: minetest-technic: Update to 2021-09-11 Maxime Devos
2022-01-03 15:22 ` [bug#52977] [PATCH 6/6] gnu: minetest-unified-inventory: Update to 2021-12-26 Maxime Devos
2022-01-05 22:30 ` bug#52977: [PATCH 0/6] Update some minetest packages Ludovic Courtès
2022-01-05 23:18 ` [bug#52977] " Maxime Devos
2022-01-06 0:52 ` Liliana Marie Prikler
2022-01-06 9:33 ` Maxime Devos [this message]
2022-01-06 15:49 ` Liliana Marie Prikler
2022-01-11 12:53 ` Ludovic Courtès
2022-01-11 13:20 ` Maxime Devos
2022-01-05 23:21 ` Maxime Devos
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e95947b2ae0fe183c5dc1e5699998a56d06fd61d.camel@telenet.be \
--to=maximedevos@telenet.be \
--cc=52977@debbugs.gnu.org \
--cc=liliana.prikler@gmail.com \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).