GNU bug report logs - #73833
[PATCH] guix: import: composer: Improve composer-fetch.

Previous Next

Full log

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

From: Nicolas Graves <ngraves <at> ngraves.fr>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 73833 <at> debbugs.gnu.org
Subject: Re: [Nicolas Graves via Guix-patches via] [bug#73833] [PATCH v2
 5/5] guix: refresh: Implement basic upstream-source-inputs rich updates.
Date: Thu, 07 Nov 2024 09:58:17 +0100

On 2024-11-06 17:11, Nicolas Graves wrote:

> Thanks for your review, I'll update the patch series.  Just to let you
> know I've also implemented a more elaborated input->update-spec when
> working on hackage import with versions. Don't bother reviewing this 5/5
> one, I'll update it too which welcome changes from there.

Actually I have some questions about this before reworking further on
that.  As I said, I have also worked on the hackage one, and I come to
think that a single min-version and max-version is probably not the best
way to tackle this.

The reason behind this is that most other package managers are relying
on either semver with carets or >/>=/</<=/==/||/&& operators to resolve
the requirements.  The problem with min-version or max-version currently
is (IIRC) that when we define them, we don't necessarily have an
overview of available versions, and, because of that, it's really
difficult down the line in input->update-spec to properly select a
(targeted!) version. (especially if < or > is used).

Instead we could keep a requirements field, and have a function
(resolve available-versions requirements) that returns the valid
versions among available-versions.  Otherwise I have the impression I'm
playing with hacks just to comply with the min-version and max-version
fields.

WDYT ?

-- 
Best regards,
Nicolas Graves

Previous Next

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