chore: update gappa to version 1.6.0

[Justme0606]

No description provided.

[jmid]

Thanks!

On the CI the two MinGW workflows fail to find bison because conf-bison doesn't support MinGW ATM 🤷

More interestingly, there is a single failure on x86_32 with OCaml 4.14:
https://opam.ci.ocaml.org/github/ocaml/opam-repository/commit/65fa29ce602d4d463a170e0c6d224858a4a186f4/variant/extras,x86_32-ocaml-4.14,gappa.1.6.0

#=== ERROR while compiling gappa.1.6.0 ========================================#
# context              2.5.0~beta1 | linux/x86_32 | ocaml-base-compiler.4.14.2 | pinned(https://gappa.gitlabpages.inria.fr/releases/gappa-1.6.0.tar.gz)
# path                 ~/.opam/4.14/.opam-switch/build/gappa.1.6.0
# command              ~/.opam/opam-init/hooks/sandbox.sh build ./remake --jobs=71
# exit-code            1
# env-file             ~/.opam/log/gappa-7-b6aa76.env
# output-file          ~/.opam/log/gappa-7-b6aa76.out
### output ###
# Failed to locate Remakefile in the current directory or one of its parents

Looking briefly at https://gitlab.inria.fr/gappa/gappa I'm not entirely sure what is causing this. IIUC, the repo seems to vendor a copy of remake which I think is the one failing. It is failing on x86_32 with 4.14 (with native code compilation) but passing on x86_32 with 5.x (with bytecode compilation). Simultaneously both the 4.14 and 5.x workflow for arm32 are passing, so it doesn't seem to just be a 32-bit issue... 🤔 Any ideas?

[Justme0606]

Thanks!
After discussing it with a colleague, I assumed the issue was in the conf-bison depexts, and that we needed to add the following for gappa to work:

[ "bison" ] { os-family = "cygwin" }
[ "bison" ] { os-family = "msys2" }

But I’m not an expert at all, so I may be mistaken.

[jmid]

Yes, to avoid the bison error on the MinGW workflows we should consider adding something like this to conf-bison - not here though. It is however tricky, as the bison executable will depend on Cygwin1.dll on Cygwin-MinGW, whereas with Cygwin-MinGW we are trying to build programs that don't have this dependency. 🤔

Anyway, since that is a conf-bison issue, it is not a problem with your package.

I was curious to hear your thoughts on the x86_32 OCaml.4.14 failure...

[jmid]

LGTM, thanks!

IIUC, the 4.14 vs 5.x differences for x86_32 was a red herring, as this seems to be a C++ project and hence independent of the OCaml version.

Anyway: Would you consider adding an x-maintenance-intent entry?
https://github.com/ocaml/opam-repository/blob/master/governance/policies/archiving.md

[Justme0606]

Hello!
Yes, sure.
I still have a few adjustments to make, so I can add the x-maintenance-intent entry.
However, I’m not the maintainer of this package. I only worked on it as part of the Rocq Platform release preparation.

So I’m not sure whether I’m the right person to set this field, and I don’t want to make a mistake.
What would you recommend?

Have a nice day,
Best regards,

[jmid]

Hm, since this seems to be a C++ project packaged with opam, I suppose maintenance primarily means maintaining the opam-files here on the opam-repo and help communicate any issues from users reported here.

Now, admittedly there aren't that many opam-repo releases with 1.3.5 being added 5 years ago, 1.4.0 4 years ago, and 1.4.1 2-3 years ago. Furthermore these are only a selection of the actual releases it seems: https://gitlab.inria.fr/gappa/gappa/-/tags

With a continuous stream of regular releases, I suspect that x-maintenance-intent: ["(latest)"] will be a reasonable fit.
The alternative is to wait and add something like it to your next public opam-repo release.
The current policy is to retain all releases, but that may change at some point, e.g., to retaining only latest by default.
So, if the next opam-repo release is 2-3 years out, someone here may have decided for you in the meantime... 🤷
As such, now is probably a good time for you folks to decide among yourselves which of the past versions need to be retained (and maintained).

P.s. I try to remember to ask this question on all package PRs missing an entry. From a resource perspective it is of course more relevant to reduce a package in 30 versions than one with 3... 🙂

[Justme0606]

Ok I understand ! Thanks for your explanations.
I added x-maintenance-intent: ["(latest)"]
Have a nice day