bug#62698: closed (bind:utils)

[GNU bug Tracking System]

Your message dated Thu, 04 May 2023 08:43:34 -0400
with message-id <877cto6zd5.fsf@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@gnu.org.)


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

--- Begin Message --- Subject: bind:utils Date: Thu, 6 Apr 2023 14:43:29 +0300

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

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#62698: bind:utils
>
>
>
>
> Date: 
>
> Thu, 04 May 2023 08:43:34 -0400
>
>
>
>
> User-agent: 
>
> Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
>
>
>
>
> Hi Brian,
>
> Brian Cully <bjc@spork.org> writes:
>
> > Maxim Cournoyer <maxim.cournoyer@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
>
>
> --- End Message ---