Closed dbuenzli closed 8 years ago
As shown by the debug mode, what opam currently does -- which seems quite sub-optimal, is:
--dry-run
, and a -p
parameter ranging from -p0
to -p4
, until one succeeds--dry-run
The reason to do this was, I believe, that it's hard to know what -p
parameter the patch expects, and that trying without --dry-run
could lead to a partial application; but besides being ineffective, it also means we had to discard error messages from patch
in order not to be overly verbose.
I can see a few ways out:
--dry-run
with something like -o /dev/null
, which might be functionally equivalent.--dry-run
, but reset the source tree each time to be sure. Even less efficient...-p
parameter, and enforce 1, which is the standard for patch files generated from VC tools. Patches in the repository appear to use either 1, or be based on /tmp/opam-xxxxx-xxxxx/
, which we could fix mechanically.I agree the current situation is not very nice, esp. w.r.t. the lack of error reporting. What do you think ?
be more strict on opam repository about the -p parameter, and enforce 1, which is the standard for patch files generated from VC tools. Patches in the repository appear to use either 1, or be based on /tmp/opam-xxxxx-xxxxx/, which we could fix mechanically.
I'd say this (and mention in in the docs) or maybe you can keep it as is now and simulate a --dry-run
with -o
.
Here's the POSIX spec and a problematic tool:
The current behaviour also leads to misleading error message:
Debug mode: