GNU bug report logs - #65062
[PATCH core-updates] packages: Lookup inputs by specification.

Previous Next

Full log

View this message in rfc822 format

From: Hilton Chain <hako <at> ultrarare.space>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Josselin Poiret <dev <at> jpoiret.xyz>, Simon Tournier <zimon.toutoune <at> gmail.com>, Mathieu Othacehe <othacehe <at> gnu.org>, Tobias Geerinckx-Rice <me <at> tobias.gr>, Ricardo Wurmus <rekado <at> elephly.net>, 65062 <at> debbugs.gnu.org, Christopher Baines <guix <at> cbaines.net>
Subject: [bug#65062] [PATCH core-updates 1/1] packages: Specify output in input label when it's not "out".
Date: Thu, 24 Aug 2023 11:42:04 +0800

Hi Ludo,

On Wed, 23 Aug 2023 00:00:00 +0800,
Ludovic Courtès wrote:
>
> Hi,
>
> Hilton Chain <hako <at> ultrarare.space> skribis:
>
> > * guix/packages.scm (add-input-label): Specify output when it's not "out".
>
> [...]
>
> > +         (list (string-append (package-name package) ":" output)
> > +               package
> > +               output)))
>
> The Grand Plan¹ is to eventually get rid of labels entirely (or almost:
> there’d still be input alists on the build side).  As such, I thought we
> shouldn’t worry too much about what the actual label is.  But perhaps
> you stumbled upon situations where this is a problem?  Could you
> describe them?
>
> Thanks,
> Ludo’.
>
> ¹ https://guix.gnu.org/en/blog/2021/the-big-change/

My main concern is that currently modify-inputs, this-package-input
and this-package-native-input operate on input labels and there would
be duplicated labels if adding multiple outputs of a package.

For modify-inputs, I think there's no approach to solve this without
also specifying labels in inputs.

Although this-package-* can be replaced by search-input-*, I'd like to
avoid (dirname (dirname (search-input-file inputs "/lib/..."))) when
(this-package-input "...") is available.


For current this-package-* vs. search-input-*, I have other points:

1. In the context of build system arguments, like #:configure-flags,
inputs and native-inputs as variables aren't available, one may need
to use %build-inputs, %build-host-inputs and %build-target-inputs for
search-input-*, which is inconsistent with other parts.

2. It might be a bit confusing when, for example, adding
tzdata-for-test to native-inputs, and referencing it with proper
cross-compilation support:
--8<---------------cut here---------------start------------->8---
(setenv "TZDIR"
        (search-input-directory
         (if #$(%current-target-system) native-inputs inputs)
         "/share/zoneinfo"))
--8<---------------cut here---------------end--------------->8---

In such cases I may prefer this-package-*, but it would be unreliable
when there're duplicated labels.


There's also issue referencing a package when multiple versions of it
under a same name are added to the inputs, which may not fall under
this "Subject:".


Thanks

Previous Next

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