From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id yOZ1JgTUK2W1PQEA9RJhRA:P1 (envelope-from ) for ; Sun, 15 Oct 2023 13:59:00 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id yOZ1JgTUK2W1PQEA9RJhRA (envelope-from ) for ; Sun, 15 Oct 2023 13:59:00 +0200 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 4D7C05EED6 for ; Sun, 15 Oct 2023 13:59:00 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=Ni5eyZ8g; dmarc=pass (policy=none) header.from=posteo.net; 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" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1697371140; a=rsa-sha256; cv=none; b=r0Uu3Ycw8KyLwCpTmS5T3osPV8c29ALSko6WI75B2wgrwm/p69k/H5Y9S5HB3ce1Ns4aWo BolQj0hLSE9C9WenXfZR9okOWCSnPm8msYlQGePlEMVnRPUAr6T4fUgS3Yd5Qmw/sM4YrL Bowqq//3rp+e1AypTNNpkgfKjBugWK13VjYnJxiuE6/hY4kMirOMyejidc3ZuFG8Bmc+fk FVNWS9e0Q8Pw7b3BqlvwoJd2rMnOepuwzmMFRKk543gGFVqWATdtnvJo0gCCPu7L6bsagT pg7EwDqmlOfINVOC2aD7JgUQzVLDyGBxAVl31OnIUGGx2BIsDGy+DmbHwB7SpA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=Ni5eyZ8g; dmarc=pass (policy=none) header.from=posteo.net; 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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1697371140; 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:dkim-signature; bh=kZqiuS7OQI9buBOjp5CM4Qy9cfeUQewnOXjoV/Vzs/Q=; b=YLOBCcbOFh2lAsgVrrGOj+zONfQ8H+IJA7FzI1n25B1Rg/J2Fpu/2bUeVk7fHLVdpkKPx9 ORT4sI5lOTUps6iLBAZN5wu2rmpbFAP08whpbQN+OgQvZFhNH+E36L3TJQRnaQvrn2odPV 0WubwqAL7Q/EaGymUcQlF9FLC29VIgeJTmlfQ9zpeo1++uVgIG++BcVvzE/ODZQd35Rj6j c0Xlil65RbmH2c4kAVQpz7WIOb/vbAAKtM2tL649ABeZljGOZtdGSSW2oi6gqfZqFrDLcu XDabdmgpJlyUN2zzDcON65WBJseE3p5DvbYwy3BAgupXMaRikZPfKyU/vBJOjA== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qrzlD-0004bU-Jp; Sun, 15 Oct 2023 07:58:19 -0400 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 1qqIgk-0003c7-80 for guix-devel@gnu.org; Tue, 10 Oct 2023 15:46:43 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qqIgh-0002iu-NN for guix-devel@gnu.org; Tue, 10 Oct 2023 15:46:41 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 6AF97240104 for ; Tue, 10 Oct 2023 21:46:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1696967196; bh=kM5YGt8E+VyR8LG05scCyzSfeQf5SQF9Gj6aJAnN6nw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:From; b=Ni5eyZ8gSvEDFk+glRFMy12NXyq5xv+0RgDF4cGJeFqNU12aki+Y/gQ0cOnIiA9Rv vq0v3pS0dIVe1p5fjTxkTrav+0w3no0M6w8K+20WkqKF6MSJ7V1u1jLSfpUvKwVLpZ w10XJpCoqXr9EdYt+Xw5vDiVLGqMK8nvLdAiqCaextjZtWctcfFlqTCfF98+gNOsSs w22LC0mgimwIhF4/ELFCShzb+FZbJLJh4ekpWMZaxTy2dxmLS8wHrLrYm8lZ/iVa6X 4y/9StF1NaCQ466Nr6ZJyq6JMkXRQMEuwKiRJpAR/R9ZMCMDRfC7/hGhqsqg/eYiWe 8KgStTIWvp2iw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4S4mcW3JkGz9rxP; Tue, 10 Oct 2023 21:46:35 +0200 (CEST) From: Fredrik Salomonsson To: John Kehayias , Ekaitz Zarraga Cc: guix-devel@gnu.org Subject: Re: Fw: Question regarding qmk firmware In-Reply-To: <87o7h88twj.fsf@protonmail.com> References: <87r0m6xh3c.fsf@posteo.net> <87o7h88twj.fsf@protonmail.com> Date: Tue, 10 Oct 2023 19:46:33 +0000 Message-ID: <87il7eqmzq.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.67.36.66; envelope-from=plattfot@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sun, 15 Oct 2023 07:58:18 -0400 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-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx1.migadu.com X-Migadu-Spam-Score: -8.89 X-Spam-Score: -8.89 X-Migadu-Queue-Id: 4D7C05EED6 X-TUID: U+5HHGXDeg3s John Kehayias writes: > Hello, > > On Sun, Oct 08, 2023 at 10:34 AM, Ekaitz Zarraga wrote: > >> Hi >> >> I want to forward this message to guix-devel because it is a clear >> case of some (actually good) technical decision affecting users in >> unexpected ways. >> >> Now, after the change, a user might run `guix search avr-toolchain` >> and find nothing. Same for ARM. >> > > In this case would it have helped to deprecate the package? Or can we > (ab)use this as a way to notify a user that either something has > changed (use a procedure now) or that a package you might expect at > this name is available some other way? > >> This is a shame, because we have toolchains for those architectures >> but converting them to a function that returns the package leave many >> users that are not used to read guix's code thinking those packages >> are gone. >> >> Maybe we should create some kind of fake packages that show up in >> `guix show` and `guix search` that have a short tutorial on how to use >> packages that come from a function like these. >> This way providing the same interface for every package regardless >> where they are coming from. >> > > At the very least this should be documented, perhaps adding to > information about the kernel in the manual and generally > customizing/building your own. > > I like the idea in general of making sure people can find things and > if they are not where you'd expect not having a hard time to find > them. Some tips in a package description about how to use or where to > look in the manual for information would be good, but I don't think > we'd want to get too verbose here, adding another maintenance point > that should be proper documentation (or cookbook). > > As an example, we don't need to always say how to add udev rules from > a package, but letting users know (if it is not obvious from the name) > that rules are included and should be added to a system configuration > for something to work (pointing to the manual about udev service) I > think can be helpful. I don't know though, I guess the package's > documentation itself needs to tell a user how to use it, and then one > looks in the Guix manual how to add udev rules. > > Anyway, perhaps I run on a tangent here. > > John > >> I leave it as food for thought. >> >> Thanks, >> >> Ekaitz >> >> Adding my two cents here as a user. It would be great to have some sort of documentation about this. Just a tiny snippet on how to use them will be sufficient. And a guix pull --news that notified you about the packages changed to procedures. It was not obvious to me when avr-toolchain disappeared how to proceed. I had to look in the commit log to figure out what happened to it (the issue tracker would probably also have worked). Even then it wasn't super obvious how I would use them as my mind was fixed on the `guix shell PACKAGE0 PACKAGE1 =E2=80=A6` workflow. I never really use mani= fests as I have guix home to handle all my packages, and guix.scm for package development. --=20 s/Fred[re]+i[ck]+/Fredrik/g