Nicolas Goaziou <[email protected]> writes: > Mathieu Lirzin <[email protected]> writes: > >> It depends if this feature is essential for using xcas? If yes then >> adding it as a propagated-input is still not required unless "latex, >> makeindex, ..." are used using the PATH which could not be the case >> since those programs are checked at configure time. > > I removed perl, tcsh, texlive-minimal as inputs, and tried > > guix environment --ad-hoc texlive giac-xcas --fallback -- xcas > > I could preview the sheet using LaTeX. However, I sometimes got > > sh: pstopnm: command not found > sh: pnmtopng: command not found
with texlive-minimal as input, and without texlive in the environment do you get some errors? > Also, texlive-minimal is still in the closure, probably due to some > other input, so it doesn't reduce the size of the package. OK, so no real benefit. :) >> Looks good to me. guix lint is happy and the build is reproducible. I >> have modified the indentation to follow our “custom” Emacs rules. Here >> is the updated patch. > > Funnily, I broke Emacs indentation on purpose because other package > definitions in the file were disagreeing with it. I should have trusted > good ole Emacs. Yeah it is a known problem. Some people don't use Emacs so they are likely to introduce indentation mistakes. Emacs + rules from .dir-locals.el is our reference indentation (minor some emacs bugs). >> Is there a particular reason for not patching this within the >> ‘arguments’ field? > > This is because the test issue is related to a given release, i.e., > a given `source' field. OTOH, `arguments' are for control over the build > process, which is not going to change anytime soon. > > To put it differently, I put the temporary fix in `snippet' and the > persistent one in `arguments'. OK, I understand what was the intention. However I don't think we usually make this sort of distinction. The ‘arguments’ field is for general purpose build customization, whereas The ‘snippet’ field in origin is meant for removing/modifying parts of the code that don't respect GNU FSDG. It is done this way so that when the user is doing ‘guix build --source PACKAGE’ to get the tarball, a freed version is provided instead of the one from upstream. > Moreover, you suggest to merge the two fixes into a single phase named > `fix-makefiles', which, albeit correct, is less accurate than > `patch-bin-cp'. I think you are right, could you send an updated patch with two separate phases? Sorry I love nitpicking. ;) Thanks, -- Mathieu Lirzin
