linting produces false positives on compiler releases

[shonfeder]

See, e.g., ocaml/opam-repository#27915 (comment) and ocaml/opam-repository#27613

The following are the specious linting problems for the compiler

1. Error in ocaml-variants.5.4.0~alpha1+options: No package source directory provided.
2. Warning in ocaml-compiler.5.4.0~alpha1: The package has a dune-project file but no explicit dependency on dune was found.
3. Error in ocaml-base-compiler.5.4.0~alpha1: No package source directory provided.
4. Error in ocaml.5.4.0: conf packages should always use the 'conf-' name prefix, the 'conf' flag, and the 'depext' field all together, but this package only has the 'conf' flag

And an explanation of why they are not relevant is provided here: ocaml/opam-repository#27915 (comment)

Thanks to @ivnhk for noting this as a recurrent issue.

I am guessing that the first step in tackling this is to analyze out ocaml/opam-repository#27915 (comment) in comparison with our current logic for these checks to figure out how we can account for this case.

It's possible that special casing the compiler releases may be our only option, but where possible we should opt for more general fixes.

[ivnhk]

@shonfeder I'll take this one as I know the context more or less

[ivnhk]

upd. I've completed the initial investigation. I have a few ideas and potential solutions. Those are to be discussed with @shonfeder before we move to the actual implementation :)

[shonfeder]

We discussed this with @mseri at the maintainer meeting last week. Our upshot at the time was that the compiler release process is not yet stabilized, and that it is likely premature for us to invest much in tackling these noise issues, since releases are infrequent and always reviewed by domain experts who know how to filter out the noise currently. In short, we learned that our energy would be better spent addressing other issues for the time being.

@ivnhk, would you be up to share your notes here, so that they will be available for if/when we return to this issue?

[shonfeder]

Also, if anyone involved with the compiler releases knows better and thinks that the process is now stable enough, and the noise onerous enough that we should prioritize working on this, please send word!

[ivnhk]

@shonfeder sure

Ideas

1. No package source directory provided.

• We can handle packages that have compiler and avoid-version flags differently. For example, packages/ocaml-variants/ocaml-variants.5.4.0~alpha1+options/opam has flags: [ compiler avoid-version ]
• Detect that the package is not “independent” (meta-package) by parsing dev-repo url. In case the repo name does not match package name -> package is probably a meta package.

2. The package has a dune-project file but no explicit dependency on dune was found.

• We can check the build field in .opam file and actually see if it uses dune - if it’s not, we should not throw errors/warnings related to dune

3. conf packages should always use the 'conf-' name prefix, the 'conf' flag, and the 'depext' field all together, but this package only has the 'conf' flag

• Do a separate case for this?

Potential solutions

Handling compiler AND meta packages differently (based on avoid-version flag or any other field, for example)

No package source directory provided.

I saw this issue in our tests (lint.t) and it’s also occurring in case of metapackages: ocaml/opam-repository#27613 (comment) (in that particular case, Rocq)

At the moment, the function that returns this error looks like this:

let check_package_source ~pkg_src_dir
    : lint_check =
    fun ~pkg opam ->
    if Option.is_some pkg_src_dir ||
       (* conf packages generally don't have sources.
          See https://opam.ocaml.org/doc/Manual.html#opamflag-conf *)
       is_conf_package opam
    then
      []
    else
      [ (pkg, NoPackageSources) ]

As I see it, the reason why the CI posted an error is because ocaml-variants.5.4.0~alpha1+options (or any other package) does not have:

• a url field in opam file

It seems that CI expects every package to be mostly “independent”, meaning it could have a tarball and would be built.
Yet, as I understand, for meta packages there’s no separate tarball.

Octachron specified that in case of compiler packages, such behavior is intended

This is intended, the source is defined by the ocaml-compiler package in order to avoid duplicating the complex build configuration.

I think we need to figure out how to mark 1) meta packages and 2) account for source specified elsewhere (can we even do it?)

The package has a dune-project file but no explicit dependency on dune was found.
I think this one is kinda related to Linting can produce specious The package seems to use dune but the dune-project file is missing errors.

Octachron also noted:

Warning in ocaml-compiler.5.4.0~alpha1: The package has a dune-project file but no explicit dependency on dune was found. The compiler is not built with dune, and thus has no dependencies on dune.

We need a more sophisticated way to check if the dune is actually used for a build. We can check the build field in .opam file and actually see if it uses dune - if it’s not, we should not throw an error or a warning

conf packages should always use the 'conf-' name prefix, the 'conf' flag, and the 'depext' field all together, but this package only has the 'conf' flag
I think in general this is correct, it just does not apply in case of ocaml compiler packages. I don’t have any other ideas other than special casing this.