Ludovic Courtès writes: > Mark H Weaver <m...@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