guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] gnu: Add giac-xcas


From: Mathieu Lirzin
Subject: Re: [PATCH] gnu: Add giac-xcas
Date: Tue, 12 Apr 2016 01:21:46 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Nicolas Goaziou <address@hidden> writes:

> Mathieu Lirzin <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]