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

[Mark H Weaver]

Kei Kebreau <address@hidden> writes:

> Mark H Weaver <address@hidden> writes:
>
>> 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
>
> I'm leaving this message here to let everyone on the list know that this
> patch is being worked on. :-)

Excellent, thank you!

At this point, you should probably do this work on core-updates.

     Thanks,
       Mark