From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id gMkhCBRM1WR0oAAASxT56A (envelope-from ) for ; Thu, 10 Aug 2023 22:44:04 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id YFprBxRM1WQVIAAAG6o9tA (envelope-from ) for ; Thu, 10 Aug 2023 22:44:04 +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 23C023B13E for ; Thu, 10 Aug 2023 22:44:03 +0200 (CEST) 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=1691700243; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post; bh=WmjKRnB8sEDhIInUwaa9UwZYeBLOtFOHBddOOVJ0MAw=; b=Li5vQQ/1mMqSJzeP5n4nre3RO3AwLA9eQ8oT9ngANMqKazu+e3nQznckT5XiiAoykgGcdb jqrm8Be29nExQ22oavEf5bNH/+ZOzpH8j/5CjJVLqPpZIvYUUevY9qLpnvlF+Hi4T+8re8 UXepV7O4Zlk5SYpQC1ScsTYfyk+eEv/I9JRQ5XqtloAQ7lDx0yGZZhxCKBcjmO4zACkMnh EEk5E7CMj517yrvzenALpWUJZXVpoRuqhWYQq2M2Ds1VhLW+KVPCZRudaCfOyzIb6gjXHE WVpfEFLfoN43DHK0gzvNlghwVgcmcAxY+gRFjZ2hO3zVqTprpmQNYTxB7pU/pA== 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=1691700243; a=rsa-sha256; cv=none; b=fjusw6qYjEB1BTDcu/PN7R38YlqFFVGWcS9G3xA9LDY5Q6HsMRXx5xvNJkvrSktcV3eJSH BVgO+6s5NJbE+s29WoEbZYMl8QNTIS9HY2AbbcAt7iYgDpS0VYEdCoch7nrDrnzTFvJQs+ dJV+YbFp6nrpMz6SNmTvi5Bx/d5qM27BMg9D+H2iMKRjdNzf8Bo0v2ZNyyoBpOy/+JIEAw FDm23zqR8BFHv+GPDPO8mTaEMMaIkrW4on0XneCloB/cEqFsfsQOeZOunAinuDU8WaLl4u 1RCMXCUlGtHjQUgMjvgINTyt22rzQZjPbI/wByB4rjgTnfxm4nsobEynLchyJQ== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qUCVE-00033b-1F; Thu, 10 Aug 2023 16:43:28 -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 1qUCV9-00033M-0f for guix-devel@gnu.org; Thu, 10 Aug 2023 16:43:24 -0400 Received: from world.peace.net ([64.112.178.59]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qUCV7-0007kx-8Q for guix-devel@gnu.org; Thu, 10 Aug 2023 16:43:22 -0400 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qUCUh-0008LS-TH; Thu, 10 Aug 2023 16:42:56 -0400 From: Mark H Weaver To: Maxim Cournoyer Cc: Simon Tournier , Tobias Geerinckx-Rice , Guix Devel Subject: Re: The package/inherit trap In-Reply-To: <87sf8uewz7.fsf@gmail.com> References: <20230221130600.18932-1-sharlatanus@gmail.com> <20230226004406.6215-1-sharlatanus@gmail.com> <87ilfmhkuh.fsf_-_@gnu.org> <87lekijcwi.fsf@gmail.com> <87v8jixg6u.fsf@gnu.org> <87o7p94yqk.fsf@gmail.com> <87jzzxy6l0.fsf@nckx> <86lek8dbsf.fsf@gmail.com> <87bkl4y0kh.fsf@gmail.com> <86o7p4a1yt.fsf@gmail.com> <0F2AA797-A329-4E6D-924E-AF5AB9F89064@tobias.gr> <86v8jb8vby.fsf@gmail.com> <87h6pbojgn.fsf@netris.org> <87sf8uewz7.fsf@gmail.com> Date: Thu, 10 Aug 2023 16:40:57 -0400 Message-ID: <878raid40b.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=64.112.178.59; envelope-from=mhw@netris.org; helo=world.peace.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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-Queue-Id: 23C023B13E X-Migadu-Scanner: mx1.migadu.com X-Spam-Score: -4.68 X-Migadu-Spam-Score: -4.68 X-TUID: cW8Nyo8anGWN Hi, Maxim Cournoyer writes: > Mark H Weaver writes: > >> Simon Tournier writes: >>> and in the light of this discussion, 5f83dd03a2 seems incorrect, no? >> >> I agree that commit 5f83dd03a2 is incorrect. 'kodi/wayland' is quite >> clearly a case where 'package/inherit' should be used. > > Would you be able to write a bit of doc explaining when both should be > used? It's a common pitfalls among contributors, and I suspect few of > us have an understanding good enough to write it down in a manner clear > enough to be understood by new contributors. I don't have time to write the doc, but I can offer a few words here. The fundamental question that needs to be asked, to decide whether to write (define DERIVED-PACKAGE (package/inherit BASE OVERRIDES ...)) or (define DERIVED-PACKAGE (package (inherit BASE) OVERRIDES ...)) is this: if BASE had a replacement, would it make sense to apply the same OVERRIDES to BASE's replacement to automatically create a replacement for DERIVED-PACKAGE? Consider 'kodi/wayland' as an example: __ (define-public kodi/wayland ____ (package ______ (inherit kodi) ______ (name "kodi-wayland") ______ (arguments _______ (substitute-keyword-arguments (package-arguments kodi) _________ ((#:configure-flags flags) __________ `(cons "-DCORE_PLATFORM_NAME=wayland" _________________ (delete "-DCORE_PLATFORM_NAME=x11" ,flags))))) ______ (inputs _______ (modify-inputs (package-inputs kodi) _________ (prepend libinput __________________ libxkbcommon __________________ waylandpp __________________ wayland-protocols))) ______ (synopsis "Kodi with Wayland rendering backend"))) Suppose, at some future time, 'kodi' were given a replacement named 'kodi-with-fixes' to apply a security update. The question to ask yourself is this: would it make sense for 'kodi/wayland' to automatically be given a replacement field defined exactly as above except with (inherit kodi) changed to (inherit kodi-with-fixes)? If the answer is "yes", then use (package/inherit BASE OVERRIDES ...), and make sure that BASE is simply a variable name. If the answer is "no", use (package (inherit BASE) OVERRIDES ...), in which case any replacement of BASE will simply be dropped, and the new package will not have a replacement unless one is explicitly given in OVERRIDES. The rationale for 'package/inherit' is to ensure that, e.g., security updates applied to 'kodi' will automatically be propagated to 'kodi/wayland', and similarly for other packages. Unless I'm mistaken, the criterion given above is fully general, and thus sufficient on its own. However, for the sake of reducing the cognitive load on contributors, one could proceed to enumerate simpler heuristics that can be used in common cases. For example, if OVERRIDES includes a new 'source' field, the next question to ask is: does the new 'source' field make an incremental change to (package-source BASE) e.g. by simply adding another patch? If so, then 'package/inherit' might do the right thing. However, if the new 'source' field doesn't even look at (package-source BASE), then it's certainly not going to work sensibly when applied to BASE's replacement. Another common case is when the package you're defining *is* BASE's replacement. In that case, you certainly don't want to use 'package/inherit'. If you want to rename 'package/inherit', I'd suggest something like 'package/inherit-with-replacements'. Hope this helps. Feel free to do as you wish without consulting me further. I'm using a private branch that hasn't been merged with upstream Guix since April 2021, so your decisions won't affect me in any case. Mark