From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id YNewOohbvmUDUQEAe85BDQ:P1 (envelope-from ) for ; Sat, 03 Feb 2024 16:28:09 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id YNewOohbvmUDUQEAe85BDQ (envelope-from ) for ; Sat, 03 Feb 2024 16:28:09 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1706974088; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=cH97ZKi5hqlhAlq67EmI62xVNAH6rPwMDXzdF1EvoVI=; b=Xcv7Br3Q3nT5a7Ow5E5ABslTydLFruHfLFezAYXEwkttHbD6o02nDJFVyuDQk2BQB0gOSC TsryEB3DaMO6WpYECBDEmtsgBcJY783lmf+37/zluAcVODd9Riu2U4blU6llwVrnpqFyHE 3RaFNtmXOugidAw9biwOiI40lWPbG5Z9mygOdU0VWWmWFIyM5sLu8kkvRg/9vZYE9jkcTz rtA9tO/sMCaDZo6DBuRY7IJiIFiUb7NSAlFJOl0OPyedEWMTcxFoWwj21I+aQ3T/bo+cnE YQ4ER6G26D2nvLjbX5fuGmIIcEm3V02H/T6gb9HG7tcvrCJbcSOWwqMnXqxJ9A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1706974088; a=rsa-sha256; cv=none; b=WVL2rMxbu54Rv8nGJRgLLBWLv5XuWHo7Gf6UPmzdmBaY+7aNVeGHfFpdGejrJyRNuJ8A1I t7lS3pS/r9IohhiUqa4qUaTEPKMKfQj6Jxo9kk/ULT+LdDwx9UCKtHRpHIumtVryiLfuTI SkZvAIyiZEabtEp4EkLTxSADA8n/+B2uBbqLIKU5UKgKAvc8JIBbreaintGXNG8/LT95zO AyCtHvHB9bxPuY7Fl1JEhTq2//9pF9JnZu5dvCMRVSlqon993Dhg46BMRwJhVuI+5y9sAs 8s1TTySXCZyR/dYOHXAVLgazvAIEqkYCss10ofVffsooDsMwQOPmUEbVJ6A7Kg== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id D86DC52B46 for ; Sat, 3 Feb 2024 16:28:08 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rWHva-0004ZT-9H; Sat, 03 Feb 2024 10:27:34 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rWHvY-0004ZD-P7 for guix-devel@gnu.org; Sat, 03 Feb 2024 10:27:32 -0500 Received: from vmi993448.contaboserver.net ([194.163.141.236] helo=mutix.org) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rWHvW-0004dg-3t for guix-devel@gnu.org; Sat, 03 Feb 2024 10:27:32 -0500 Received: from [192.168.1.172] (host86-132-246-87.range86-132.btcentralplus.com [86.132.246.87]) (Authenticated sender: cdo) by mutix.org (Postfix) with ESMTPSA id 728DAA63618; Sat, 3 Feb 2024 16:27:27 +0100 (CET) Message-ID: <0109ba4a-f62f-b438-c0ba-f46e66395a7e@mutix.org> Date: Sat, 3 Feb 2024 15:27:26 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Subject: Re: Mechanism for helping in multi-channels configuration Content-Language: en-US To: Simon Tournier References: <87v875kf5u.fsf@gmail.com> Cc: guix-devel From: Christina O'Donnell In-Reply-To: <87v875kf5u.fsf@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=194.163.141.236; envelope-from=cdo@mutix.org; helo=mutix.org X-Spam_score_int: -23 X-Spam_score: -2.4 X-Spam_bar: -- X-Spam_report: (-2.4 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.509, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -6.66 X-Migadu-Scanner: mx13.migadu.com X-Spam-Score: -6.66 X-Migadu-Queue-Id: D86DC52B46 X-TUID: vzwuoaJSqmd7 Hi Simon, > The wishlist is: provide a machine-readable description on guix-science > channel side in order to help in finding the good overlap between > commits of different channels. > > It could be nice if instead of an hard error, “guix pull” could say: > « the channel ’guix’ needs to be at least at commit 1234abc ». I was just thinking about these kinds of errors. It would also happen between channels when packages are split from a single file (eg. golang.scm to golang-xyz.scm). Then channels immediately go out of sync as we're doing continual releases. So, it wouldn't just be for time-machine. It's all a bit too fragile for my liking. I assume we won't be to frequent versioned releases any time soon.. A sketch of a solution might be:  1. Have a script that scrapes all the define-public symbols in every file in     every package.  2. Have a script that determines the symbols needed by each file. (Macros     make this more difficult, but.)  3. Have both scripts have an incremental version that runs on diffs (for     performance).  4. Run this for every commit on every branch on every channel caching the     result.  5. Have a CI script keep this updated for new commits.  6. Have a server track incompatibilities. For example, a 'definition-reference' could look like, (definition-reference (commit-range start-hash end-hash)                       file-path                       identifier) (definition-reference (commit-range "44b340d..." "06dba3b...")                       "gnu/packages/golang"                       'go-github-com-rs-xid) Commit ranges makes the size of entries tractable (since package probably aren't getting moved / deleted / added very much). Then use a hash table, (or trie or B+ Tree, or distributed hash table, etc) to go from identifier to definition-reference. You would probably would also want to know commit date so you could index on it. That would let you find versions that supplied the identifier that are as close as possible chronologically to a particular version of a different channel Now this isn't perfect (in case anyone was getting that impression ;):  - It won't have any idea about version incompatibilities.  - It couldn't trace renamed variables.  - And probably more. Might be useful to additionally track package versions, but that might run into resource issues. I'm thinking a Guile daemon backed by SQLite.. What do you think? Full disclosure: I've got nothing lined up for the summer yet, so I'm on the prowl for GSoC projects :) Kind regards,  - Christina