Subject: [bug#65351] [PATCH v2 1/7] gnu: cgit: Make git-source a native input.

From: Liliana Marie Prikler <[email-masked]>
Date: Thu, 28 Sep 2023 18:16:58 +0200

Am Donnerstag, dem 28.09.2023 um 08:12 +0100 schrieb Arun Isaac:
> 
> Hi Liliana,
> 
> Sorry for the long delay! Life got in the way.
> 
> > This patch is broken and it doesn't appear to get fixed in 4/7.  If
> > you want git-source to be in native-inputs, you need to use (or
> > native-inputs inputs).
> 
> I'm not sure what you mean. I am able to build both cgit and cgit-
> pink on my machine. The QA system also agrees with
> me. https://qa.guix.gnu.org/issue/65351
CI doesn't do cross-builds, it does simulated native builds, so you
won't see the issue.

> > Most of these patches are not really atomic, depending on each
> > other to make sense.  I'd instead possibly do the following:
> > 3
> > [1, 2, 4, 5] squashed into a single commit
> > 6
> > 7
> 
> I disagree. I do think these commits are atomic. Each one of these
> commits fixes a single independent problem with cgit that has no
> relevance to cgit-pink. Finally, the last commit adds cgit-pink. Note
> that there are already many commits in guix along similar lines. So,
> there is precedent.
> 
> * gnu: cgit: Make git-source a native input.
> * gnu: cgit: Make bzip2, gzip and xz inputs.
> * gnu: cgit: Do not return #t from custom phases.
> * gnu: cgit: Use G-expressions.
> * gnu: cgit: Add bash-minimal to inputs.
> * gnu: cgit: Use cc-for-target.
> * cgit-pink gnu: Add cgit-pink.
Indeed, there is precedent.  However, when moving stuff around, such as
in 1, you also need to update the dependent stuff, which you haven't
done and which also causes more noise along the line.  In this series,
you need three commits to basically get input handling "correct".  The
intermediate commits are duds in terms of guix time-machine, which
isn't great.

> > In 7, you might want to use /bin/sh if the compatibility is meant
> > for stuff that actually lands in the store.
> 
> /bin/sh doesn't work. I have tried. If I remember correctly, this is
> to do with how the SHELL_PATH gets substituted into generated
> scripts.
For the record, what kind of generated scripts are we talking here? 
Invoked at build time or sent to the store?

Cheers