GNU bug report logs - #62698
bind:utils

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#62698: closed (bind:utils)
Date: Thu, 04 May 2023 12:44:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Thu, 04 May 2023 08:43:34 -0400
with message-id <877cto6zd5.fsf <at> gmail.com>
and subject line Re: bug#62698: bind:utils
has caused the debbugs.gnu.org bug report #62698,
regarding bind:utils
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
62698: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62698
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Αντώνιος Τσώλης
 <tsolis.antonios <at> gmail.com>
To: bug-guix <at> gnu.org
Subject: bind:utils
Date: Thu, 6 Apr 2023 14:43:29 +0300

[Message part 3 (text/plain, inline)]

The bind:utils (dig, host, nslookup) are not copied/included in any bin
path.

[Message part 4 (text/html, inline)]

[Message part 5 (message/rfc822, inline)]

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Brian Cully <bjc <at> spork.org>
Cc: Αντώνιος Τσώλης
 <tsolis.antonios <at> gmail.com>, 62698-done <at> debbugs.gnu.org
Subject: Re: bug#62698: bind:utils
Date: Thu, 04 May 2023 08:43:34 -0400

Hi Brian,

Brian Cully <bjc <at> spork.org> writes:

> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
>
>> Thanks for finding the problem.  Should we leave this bug open until
>> specification->package+output is properly documented in our manual,
>> with
>> an example?  If yes, would you like to try your hand at adding it?
>
> I've looked at this briefly, and can't figure out a good place to
> document this (I'm also not particularly good with TexInfo).

Hm, looking at '(guix) Packages with Multiple Outputs', we already have
an example, which simply append packages and (list package "output")
lists, so perhaps that should be preferred instead.  The
'specification->package+output' procedure mostly appears to be used
internally, in (guix scripts environment) for example.

> I'm okay with closing the bug. Though I will say that I think this
> procedure is a bit of a foot-gun. Multiple value returns are always
> kind of weird, and in this particular case I don't see the value at
> all; the only reason to use ‘specification->package+output’ would be
> to get both the package and the output, so the minor advantages of
> multi-value returns are obviated. On top of that, does this even get
> used outside of system/home definitions? And in those places you
> always want a list.
>
> I realize a lot of code uses the current semantics, so changing them
> would be extremely difficult at this late stage. It's worth thinking
> about adding another procedure that does the expected thing (returning
> a list of package and output), IMHO, and transitioning over to that.

Note that for user profiles, it seems better to use manifest with the
convenient 'specifications->manifest' procedure that allows directly
providing package name/outputs via a "bind:utils" specification, for
example.

Closing!

-- 
Thanks,
Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.