Source: curl Version: 7.47.0-1 User: helm...@debian.org Usertags: rebootstrap
The curl upload mentioned above regressed in terms of cross building. Prior versions could be cross built just fine. The root cause is that this curl release starts to generate zsh completions using a perl script that runs the just built curl. Running that curl is something we cannot do during cross compilation and the build system recognizes that: | NOTICE: we can't generate zsh completion when cross-compiling! This later causes package assembly to fail. | dh_install: curl missing files: usr/share/zsh/* Example failing log (big!) at https://jenkins.debian.net/job/rebootstrap_powerpc_gcc5/84/consoleText Unfortunately I cannot provide a solution at this time, but since curl is needed for the architecture bootstrap I want to give this regression notice asap. For those interested in fixing this bug, I can sketch a few solutions to this problem, which is similar to help2man problems in general. 1) Do not ship zsh completions in cross compiled packages. This violates the principle that cross built packages should look the same as natively built ones, but occasionally it is better to back down on this principle than to have no cross building at all. 2) Have curl Build-Depends: curl <cross>, i.e. install curl for the build architecture and tell the zsh completion generator to use the system copy instead of the just built curl during cross compilation. The major downside with this approach is that there is no way of enforcing a same version restriction on the system curl. We cannot do like Build-Depends: curl (= ${source:Version}) <cross>. 3) Generate the zsh completions at tarball creation time and validate them during native builds. While this path works great for cross compilation, it means busywork for upstream. 4) Move zsh completions to an Architecture:all M-A:foreign package and have curl depend on that. This also works great for cross building and adds no busywork, but we tend to dislike the proliferation of small packages. There is a trade-off to be made here. Do you (as a maintainer) have any preference? Implementation shall follow unless someone else takes up the cause. Option 4 looks robust and easy to maintain to me, but I'm not sure that it is acceptable. Helmut
