Message ID | EciLU6suTVuLb9T4sI_sH1B8B9F0qY_1UX_JUBe3c9Akjsf51OODJT7DRKcaBqFzVmu8R-5U-sJSSj6UVV7DVGoSBXWvZ1YOQ-L8WMys81k=@protonmail.com |
---|---|
State | Accepted |
Headers | show |
Series | [bug#46852] doc: Fix reference to the bind package variable name | expand |
Context | Check | Description |
---|---|---|
cbaines/comparison | success | View comparision |
cbaines/git branch | success | View Git branch |
cbaines/applying patch | fail | View Laminar job |
cbaines/issue | success | View issue |
On Mon, Mar 01, 2021 at 04:28:27PM +0000, Luis Felipe via Guix-patches via wrote: > Change "bind" package variable name to the actual variable name, "isc-bind". > > > --- > Luis Felipe López Acevedo > https://luis-felipe.gitlab.io/ > > From 91f7ec90fbe742de6eb3c092c86d84125a56f51f Mon Sep 17 00:00:00 2001 > From: Luis Felipe <luis.felipe.la@protonmail.com> > Date: Mon, 1 Mar 2021 11:15:16 -0500 > Subject: [PATCH] doc: Fix reference to the bind package variable name. > > * doc/guix.texi (Globally-Visible Packages): Change "bind" variable > name to the actual variable name, "isc-bind". Is there a reason for this change? It's okay for packages and variables to have different names.
Leo! Leo Famulari 写道: > Is there a reason for this change? It's just weird to say ‘...now assume there's a package called bind, but there isn't, and then you could write...’ when we could use a valid package from the get-go. It's safe to assume that ‘bind’ was simply a typo, and the fix is just and good. > It's okay for packages and variables to have different names. Hm, you lose me here. The snippet clearly intends to refer to BIND-the-package (few other packages have a "utils" output), not some arbitrary user (eh) binding... Kind regards, T G-R
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, March 2, 2021 11:53 PM, Tobias Geerinckx-Rice <me@tobias.gr> wrote: > Leo! > > Leo Famulari 写道: > > > Is there a reason for this change? Oh, I should have said so in the commit message, sorry. The reason is that if I add (list bind "utils") to the packages field in my operating system definition, reconfiguring the system fails because "bind" is a built-in Guile procedure, and so the package variable for BIND is called "isc-bind" to avoid that conflict.
Hello, Luis Felipe <luis.felipe.la@protonmail.com> writes: > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Tuesday, March 2, 2021 11:53 PM, Tobias Geerinckx-Rice <me@tobias.gr> wrote: > >> Leo! >> >> Leo Famulari 写道: >> >> > Is there a reason for this change? > > Oh, I should have said so in the commit message, sorry. The reason is > that if I add (list bind "utils") to the packages field in my > operating system definition, reconfiguring the system fails because > "bind" is a built-in Guile procedure, and so the package variable for > BIND is called "isc-bind" to avoid that conflict. Applied as 0b5120fb03db5226871b3482a72b1e6fdaa59ead, thank you! And thanks to Leo and Tobias for getting the matter clarified :-). Closing, Maxim
From 91f7ec90fbe742de6eb3c092c86d84125a56f51f Mon Sep 17 00:00:00 2001 From: Luis Felipe <luis.felipe.la@protonmail.com> Date: Mon, 1 Mar 2021 11:15:16 -0500 Subject: [PATCH] doc: Fix reference to the bind package variable name. * doc/guix.texi (Globally-Visible Packages): Change "bind" variable name to the actual variable name, "isc-bind". --- doc/guix.texi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/guix.texi b/doc/guix.texi index e8fb346d73..8468b2890b 100644 --- a/doc/guix.texi +++ b/doc/guix.texi @@ -13301,12 +13301,12 @@ of a package: (operating-system ;; ... - (packages (cons (list bind "utils") + (packages (cons (list isc-bind "utils") %base-packages))) @end lisp @findex specification->package -Referring to packages by variable name, like @code{bind} above, has +Referring to packages by variable name, like @code{isc-bind} above, has the advantage of being unambiguous; it also allows typos and such to be diagnosed right away as ``unbound variables''. The downside is that one needs to know which module defines which package, and to augment the base-commit: 7ca43b0a1e2215abe0df0708f31decace8e68911 -- 2.30.0