From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:36905) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j3yhf-0003bS-C1 for guix-patches@gnu.org; Tue, 18 Feb 2020 03:58:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j3yhe-0002AW-7V for guix-patches@gnu.org; Tue, 18 Feb 2020 03:58:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:33570) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j3yhe-00029t-4q for guix-patches@gnu.org; Tue, 18 Feb 2020 03:58:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j3yhe-0007d9-4s for guix-patches@gnu.org; Tue, 18 Feb 2020 03:58:02 -0500 Subject: [bug#38408] [PATCH v9 2/8] guix: import: crate: Use semver to resovle module versions Resent-Message-ID: References: <7dbe9a73fe56e1116d3207ef3cb9547a32b9a773.1580817140.git.mjbecze@riseup.net> <87y2t17047.fsf@gnu.org> <20200217145759.GM1968@E5400> <87v9o55ioa.fsf@gnu.org> From: Martin Becze Message-ID: Date: Tue, 18 Feb 2020 03:56:59 -0500 MIME-Version: 1.0 In-Reply-To: <87v9o55ioa.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= , Efraim Flashner Cc: 38408@debbugs.gnu.org, jsoo1@asu.edu On 2/17/20 10:37 AM, Ludovic Courtès wrote: > That’s why I wrote that 0.4.6 is an approximation (probably a good one > because it’s apparently known to work.) Just grabbing the version from the semver range would work for some ranage would break on Hyphenated ranges (1.2.3 - 2), Combining ranges (>=0.14 <16) and on the asterisk range operator (1.*.* or 2.*) Currently we are just trying to pick the most recent version that fits in the semver range. > We can do something smarter, but then it’s only useful if the updater is > equally smart—that is, it can update 0.4.6 to 0.4.13 whenever that > version is out, knowing that blake2-rfc will still work fine. Yep argeed! I would like to fix the updater as well, but i thought i should wait to send that in after this one gets in. Also it can quickly turns in to a SAT problem. I think we have two basic options though. 1) update everything to the newest possible version (easiest and this is what the importer does currently) 2) make the smallest possible dependency graph for all packages (harder, involves a SAT solver)