Mark H Weaver <m...@netris.org> writes:

> Kei Kebreau <k...@openmailbox.org> writes:
>
>> Mark H Weaver <m...@netris.org> writes:
>>
>>> k...@openmailbox.org (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. :-)

Attachment: signature.asc
Description: PGP signature

Reply via email to