Add an opatch package and command-line tool

[shym]

This PR proposes to add a new opatch command-line tool to implement a pure OCaml alternative to GNU patch.

The proposal is to add this new command to the patch repository so that:

• code can refactorised easily between the opatch command and the patch library if/when that makes sense (in particular, the same licence has been chosen to make sure this is possible),
• opatch can be used (eventually) in the test suite.

It is added as a new package so that:

• opatch can depend on a much more recent OCaml version (I’d rather add support for older versions only if there’s an actual need, and using stdcompat in that case, probably),
• users of the patch library don’t end up with a new command-line tool they might didn’t want,
• opatch is currently a lot less tested than the rest of the patch library; even if it is heavily based on @kit-ty-kate’s code in opam, all the changes I’ve made where not yet tested as thoroughly.

The initial goal of this new command is to have a portable patch tool for MirageOS OCaml compilers.

[hannesm]

I think you can write %%VERSION%% and the dune subst will replace it -- so there's no need for the custom dune rule, and generating a version.ml

[shym]

I got bitten by this because this works only in dev mode. dune subst doesn’t run on release tarballs (which is reasonable as it pulls info from git describe). So the packages that use those placeholders generate explicit release tarballs where they are substituted. I find this trick simpler and lighter.

[hannesm]

Hmm, ok. My experience is when use dune-release these watermarks get replaced. But if you prefer the version.ml generated by dune rule, let's go with that.

[kit-ty-kate]

I'd rather not use dune subst

[shym]

In the aftermath of the xz-attack, I got convinced (by a talk? a post somewhere? I forget :-/) that the changes between the tagged version of the source and the actual release tarball are harmful. So much so that I’m advocating using automatically github-generated tarballs instead of user-created tarballs, to remove one link in the trust chain.

[shym]

I’ve tested this command mostly with the patches for the compiler in OCaml/Solo5.
@dinosaure: I think I remember you had larger patch series, it would be interesting to see if they are applied correctly too.

[dinosaure]

Can not really test but don't hesitate to go forward without me on this topic.

[hannesm]

Thanks. So how to move forward? Since we have some tests, could we use opatch there? From a maintenance point of view, I'd be in favour to remove src/patch_command.ml.

About dependencies and complexity, I would be happy to merge this into the patch library --- even if you plan to depend on cmdliner. Are there any downsides of having it in the same opam package?

[kit-ty-kate]

Are there any downsides of having it in the same opam package?

avoiding the extra dependency would be great. I also personally don't think we should mix binaries and libraries in the same package

[hannesm]

@kit-ty-kate which extra dependency are you talking about?

I also don't quite understand why mixing library and binary would be a bad idea - is there some reasoning behind that?

[shym]

From a maintenance point of view, I'd be in favour to remove src/patch_command.ml.

According to git grep, patch_command is not actually used in tests. I suppose it has been useful in debugging the counter-examples generated by the crowbar-based test.

About dependencies and complexity, I would be happy to merge this into the patch library --- even if you plan to depend on cmdliner. Are there any downsides of having it in the same opam package?

I don’t plan to add another dependency, but opatch is written targetting Stdlib 4.14, not 4.08. I’m not convinced about the point of supporting older versions for the binary. As the library is used by opam, it must allow for older versions, I guess.

[kit-ty-kate]

@kit-ty-kate which extra dependency are you talking about?

ah nevermind i thought this was depending on cmdliner

is there some reasoning behind that?

mostly the rule of least surprise. If someone calls opam install patch i would expect to get the patch library. If i call opam install opatch i would expect the binary. It also limits what the binary can depend on (cmdliner as you said, which i would be against if it was added as a dependency of the patch package)

[hannesm]

Ok, thank you. I'll merge and release (opatch only).