Kei Kebreau <k...@openmailbox.org> writes: > 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. :-)
Excellent, thank you! At this point, you should probably do this work on core-updates. Thanks, Mark