From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id wGQkILjpcmfkEgAAe85BDQ:P1 (envelope-from ) for ; Mon, 30 Dec 2024 18:43:04 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id wGQkILjpcmfkEgAAe85BDQ (envelope-from ) for ; Mon, 30 Dec 2024 19:43:04 +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=1735584184; 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=bAWB0bNLF+qs2rNj8ULZmd0sHh3wB/PnZOe7kyjJ3ik=; b=OBMcYEPnsdfSSsmEdmfDtk8AgWj6a1+3n6XTlyF8XhK76atV4Xfhw8Ux/aqbskWC49yvRj ZRImn7xbFwQUtnceilSJPjOGFsSaNyrLcuuFOdVAW1UiUlzl1VBsklXgUV/XocxDcJ8Ocy VV+PboEcmZrUgpKwOGMln1u55zaM2XEtW1Lf0ZHri/Gfj12fJV5uLsJtezAm8qRQv1wopi HFh2Mg0D8BurpusIBbFcN6I3vGF063+lw2/eCqhiLvid5JOuwR1p/KIlkm5Mg4s3XRgsBS DcfnPzcciPOTYH1IiMKWAhirh/3E9gzeUocnghhAoRQTGw6zn01aaRVz3jOTrw== 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=1735584184; a=rsa-sha256; cv=none; b=U8jSAzGPZ1hROq7Q7A8n032m1urLNiXAWhoeRwTRcIScTchztJEbqGBuHsHfEWy1fxYyHT 5R1lltKuMcLFuepRiuqrhGNzAcQETRprE3pDXPnfzEf3Oc9MRK7WTOM2th/0hFnsBxaf8r 0mkzxEsdcQ67QeD+f3ePask0hSw0drT7eKVTuNGI17xdN/0lIEMvrHXKyFhhVeKu+SAMET xVWUAjFtG3y0KUW1mpsbQqhFawCKBQV29kGnXT+jsi0Xpz/al12m3EnxNZXjOxWYPazfY3 Mejc7CwCAi0JvqekFmTgio2fgWgnXhsSso8iZ6PaGgli/Ko6Vhb0FEWO4C5ESQ== 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 33CEB8F0A0 for ; Mon, 30 Dec 2024 19:43:04 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSKia-0007nP-MG; Mon, 30 Dec 2024 13:42:20 -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 1tSKSU-0002D0-EM for guix-devel@gnu.org; Mon, 30 Dec 2024 13:25:44 -0500 Received: from defaultvalue.org ([45.33.119.55]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSKSS-00049B-NX; Mon, 30 Dec 2024 13:25:42 -0500 Received: from trouble.defaultvalue.org (localhost [127.0.0.1]) (Authenticated sender: rlb@defaultvalue.org) by defaultvalue.org (Postfix) with ESMTPSA id 88C8520795; Mon, 30 Dec 2024 12:25:35 -0600 (CST) Received: by trouble.defaultvalue.org (Postfix, from userid 1000) id 1F05214E066; Mon, 30 Dec 2024 12:25:35 -0600 (CST) From: Rob Browning To: Vagrant Cascadian , Ludovic =?utf-8?Q?Court=C3=A8s?= , guix-devel@gnu.org Cc: Simon Josefsson Subject: Re: Shepherd in Debian In-Reply-To: <87ttamjhm8.fsf@wireframe> References: <87o71g7ugu.fsf@kaka.sjd.se> <877c81ke4v.fsf@gnu.org> <87ttamjhm8.fsf@wireframe> Date: Mon, 30 Dec 2024 12:25:34 -0600 Message-ID: <87y0zxc9k1.fsf@trouble.defaultvalue.org> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=45.33.119.55; envelope-from=rlb@defaultvalue.org; helo=defaultvalue.org 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, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 30 Dec 2024 13:42:18 -0500 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-Scanner: mx11.migadu.com X-Migadu-Spam-Score: -3.50 X-Spam-Score: -3.50 X-Migadu-Queue-Id: 33CEB8F0A0 X-TUID: UYBAAdn3EIDM Vagrant Cascadian writes: > To avoid noise like that, it may require rebuilding the package, and the > usual detection mechanisms in Debian for things that require rebuilds > (e.g. ABI bumps in C libraries) do not appear to trigger in any way with > guile packages. While I haven't thought hard about this with respect to Guile yet, and even ignoring anything involving per-architecture binary ABIs (i.e. per-arch shared libs), I suspect the problem is "reasonably difficult", (though note that I'm mostly speaking here from a Debian perspective, and based on similar experiences with Emacs), and I would be very happy to be wrong. One option, of course, is to just omit .go files from "add on" (Guile dependent) packages, and let autocompilation (per user) handle everything. This is expensive (and who cleans up, when?), but side-steps a lot of other issues. For Guile at least, you could also ship a full set of .go files in each package (i.e. all four size and endianness combinations) with the attendant size increases, but I believe this may be insufficient, even if you were to include the "go-ABI" in the package dependencies (which would require either versioned Guile packages per go-ABI change[1], or "flag days" in unstable whenever the go-ABI changes). It may be insufficient unless every add-on package carefully versions its Scheme API, and remembers to include relevant changes to any of its public macros as part of of that API, because of course macro changes could require rebuilding all of the package's reverse dependencies. Alternately, instead of shipping go files, you could decide to just build/rebuild/remove them during package installation/removal for the installed Guile versions (guile-X.Ys), and Debian's Emacs policy tries to for emacsen, but that's also fraught (in Debian at least), given what the install/remove/upgrade maintainer script invocations allow[2]. A potential additional problem this approach creates is that you might want have just one "add on" package, say guile-foo, work with multiple Guile versions (guile-3.1, guile-3.2, etc. as Emacs policy does), but then guile-foo *and* all of its guile-related reverse dependencies need to be rebuilt/removed for a given Guile "flavor" opportunistically, whenever any guile-X.Y is installed/upgraded/removed. And *that* raises the bar substantially (again in Debian, at least), because of [2] coupled with the fact that you might need to run the rebuilds/removals in proper inter-package dependency order (unless upstream has sufficient built-in tooling for that) outside the normal apt/dpkg process. And since any given apt/dpkg run could be installing or removing various things, including guile-X.Y flavors in the same run with add-on package (e.g. guile-foo) installs/removals/upgrades, "it's complicated". [1] ...which Debian already has via the guile-X.Y versioning, *if* Guile never changes the ABI in a Z version. [2] The current Emacs policy is broken, and coming up with a fix has been difficult. The problem arose when we realized that (roughly) the only places *Debian* policy says you can count on your dependencies being available/ready are in your "postinst configure ..." and your "postinst triggered ..." (and it appears that triggers don't promise any ordering wrt deps). So, for example, you can't rely on anything outside your package or the Debian base tools (perl-base, ...) to clean up (in the preinst/prerm/postrm). Debian's current Emacs policy, had assumed (and requires) add-on packages to depend on and make calls to emacsen-common package tools from their prerm, for example, and that can (and as we saw, does) just break sometimes when emacsen-common, dependency or not, isn't properly installed. > There was a big change in Debian recently where guile was downgraded > from 3.10.x back to 3.9.x. That was a little bit exciting. Right, we had do do that because 3.0.10 was just broken on 32-bit architectures. I'm hoping we'll have a 3.0.11 we can move to for trixie. Thanks, and I hope I'm just wrong somehow regarding the complexity here. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4