Re: 01/01: gnu: wxmaxima: Update to 17.05.0.

[Mark H Weaver]

Kei Kebreau <address@hidden> writes:

> Mark H Weaver <address@hidden> writes:
>
>> address@hidden (Kei Kebreau) writes:
>>
>>> @@ -2172,6 +2176,10 @@ point numbers.")
>>>         ("shared-mime-info" ,shared-mime-info)))
>>>      (arguments
>>>       `(#:phases (modify-phases %standard-phases
>>> +                  (add-before
>>> +                   'configure 'autoconf
>>> +                   (lambda _
>>> +                     (zero? (system* "./bootstrap"))))
>>
>> In general, autoconf-style phases like this should be put after the
>> 'unpack' phase, not before the 'configure' phase.  The reason is that on
>> some platforms (e.g. mips64el-linux), the 'patch-usr-bin-file' phase
>> needs to be able to operate on the generated configure script.
>>
>> When you move the phase earlier, you may then find that you need to
>> launch the 'bootstrap' script differently, because its shebang will not
>> be correct.  That's because it will now be run before the
>> 'patch-source-shebangs' phase.
>>
>> So, the way we normally do this is to run something like:
>>
>>   (zero? (system* "sh" "bootstrap"))
>>
>> Grepping for "add-before 'configure" reveals that there are now a rather
>> large number of instances of this problem.  Oh well.
>>
>>        Mark
>
> I see. Thank you for the correction.
>
> Do you consider it worth going through the package code and patching
> this problem specifically or should it be corrected gradually while
> making other changes?

If you (or anyone else) is willing to work on this, I think it would be
quite helpful to go through and fix some or all of these problems
proactively.  It's quite common for people to look at existing packages
for examples of how things should be done, so the presence of these
mistakes in our tree will spawn new instances of the same mistake until
they are eradicated :)

Two things to keep in mind:

* If changing a package would trigger a large number of rebuilds, the
  change should be made on 'core-updates' instead.

* For each change on 'master', we should make sure the package still
  builds successfully before pushing it.  That should be enough testing
  for kind of change.

     Thanks!
       Mark