Vincent, Thank you!
This list is for general Guix discussion. Although that can sometimes include rough patches (heh), please send any future contributions to our patch tracker at guix-patc...@gnu.org — after carefully reading the ‘Submitting Patches’ section of the Guix manual.
Vincent Legoll 写道：
* gnu/packages/version-control.scm (cgit)[native-inputs]: New field.
This is no new field. Neither are those of mailutils, iwd, or graphviz!
Please rewrite all commit messages as either * gnu/packages/version-control.scm (cgit)[inputs]: Move groff & python-docutils from here… [native-inputs]: …to this new field. or * gnu/packages/version-control.scm (cgit)[inputs]: Move groff & python-docutils from here… [native-inputs]: …to here.although to be honest, I only ever use the latter format unless I'm feeling particularly pedantic.
[inputs]: Move groff & python-docutils to native-inputs.
If we run $ guix gc --references `guix build cgit`we can see that both groff and python-docutils are part of cgit's closure. This means they must to be able to run… at run time :-o Oh dear.
python-docutils's ‘rst2html.py’ is required by cgit's /lib/cgit/filters/html-converters/rst2html, and groff itself by cgit's /lib/cgit/filters/html-converters/man2html. Both of these uses look legitimate to me: they weren't accidentally captured by a stray environment variable or overzealous wrapper.
Now, it's still possible that either or both of these dependents must *also* run at build time, and for that they would need to be native indeed. Unfortunately:
$ guix build cgit --target=mips64el-linux-gnu guix build: error: gnu/packages/python-xyz.scm:2950:2:python-docutils@0.16: build system `python' does not support cross
buildsI could ignore that and pretend that all Python packages are safely architecture-independent (they're not) to continue investigating, but I'm out of time.
I don't think this particular patch adds any value at this time, so let's drop it.
The rest LGTM! Kind regards, T G-R
signature.asc
Description: PGP signature
