Re: RFC: Build system hacks for Guix do not belong in 'source'

[Ricardo Wurmus <rekado@elephly.net>]

Ludovic Courtès writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> I don't think we should be making these kinds of changes in 'snippets'.
>>
>> When I ask for the source code via "guix build -S <package>", I expect
>> freedom fixes and other bug fixes, and maybe even enhancements needed
>> for Guix that would also work fine on other systems (e.g. adding an
>> environment variable).
>>
>> However, the package 'source' should not include build system hacks that
>> are specific to Guix and would interfere with the package functionality
>> on other platforms, IMO.
>>
>> I think that both the 'ldconfig -> true' hack and the LIBDIR
>> substitution should be moved to a build phase for both of these
>> packages.
>>
>> Other opinions?
>
> I think one of the goals of ‘guix build -S’ is that you can take the
> source and build it *on GuixSD* with hopefully few additional
> modifications.
>
> From that perspective, the “hacks” are really fixes or workarounds
> (/sbin/ldconfig doesn’t exist on GuixSD.)
>
> Now, granted, there are inelegant workarounds that we’d rather hide;
> these two may well fall into this category, so I’m fine with moving them
> to a build phase.  Ricardo?

I was operating from the perspective that anything relying on "dynamic"
build information (like paths to inputs) must necessarily be implemented
in build phases, but that anything of a more static nature
(e.g. removing build time stamping, fixing Makefile problems, removing
bundled software) should be implemented with snippets.

I don't like the ldconfig hack myself (and I would be happy if we had a
replacement that would do the right thing in these cases without
requiring patching), so I'm okay with moving this into a build phase.
Expect updated patches.

It would be helpful to know where to draw the line, though, or if
there's a line at all.

~~ Ricardo