[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 01/01: gnu: wxmaxima: Update to 17.05.0.
From: |
Kei Kebreau |
Subject: |
Re: 01/01: gnu: wxmaxima: Update to 17.05.0. |
Date: |
Sun, 30 Jul 2017 21:14:36 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) |
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. :-)
signature.asc
Description: PGP signature