Depexts detection does not work on Alpine when requesting pkg@tagged-repo

[kit-ty-kate]

Detected in ocaml/opam-repository#18704

Packages of the form pkg@tagged-repo are not taken into account.
apk list --available does not say anything about the tagged-repo (though it makes pkg available even if it's not without the tag)

I would suggest to change the command that gets the list of available packages to apk policy "*" which has the following output:

[...]
pkgconf policy:
  1.7.3-r0:
    lib/apk/db/installed
    https://dl-cdn.alpinelinux.org/alpine/v3.13/main
  1.7.4-r0:
    @edge https://dl-cdn.alpinelinux.org/alpine/edge/main
capnproto policy:
  0.8.0-r1:
    @edgecommunity https://dl-cdn.alpinelinux.org/alpine/edge/community
[...]

if lib/apk/db/installed is present, the package is installed and packages available through tagged repository are shown with the repository in question.

Here is a draft of the required regexp:

Re.(compile @@ seq                                                                 
      [ bol;                                                                       
        group (rep1 @@ alt [alnum]); space; str "policy:"; eol;                    
        rep1 @@ seq [                                                              
          str "  "; rep1 @@ alt [alnum; punct]; eol;                               
          str "    "; opt (seq [group (seq [char '@'; alnum]); space]); notnl; eol;
        ];                                                                         
      ])                                                                           

[rjbou]

Tag names can be choose by user ? or it is something quite used to have the same name for those repos ?

Also, I'm wondering: if an opam package depends on a different repository (that is not by default installed), depext availability check could fail because of a missing repo. We'll have the same issue than epel, With a hint to install the new repository.

[dra27]

Apparently apk does this quite well - the error message it gives clearly states that it's from a repo which isn't enabled and says what to do to fix it (unlike dnf on CentOS in the equivalent case).

[dra27]

From this morning's meeting. This splits into three sub-problems:

• Parsing the new command above allowing capnproto@edgecommunity to be recognised as available.
• An error message heuristic with a similar idea as Display a message on CentOS if EPEL isn't enabled and depexts aren't available #4679 - capnproto@edgecommunity is not available but capnproto is available (this would be where either the user has configured the repository without a tag or the package has been moved out of an edge repository and into the main one) then in addition to the apk error, opam could suggest that the package itself might be at fault because there is a package called capnproto (and, of course, it can remind the user of --no-depexts as normal).
• In the package itself, testing commands and error messages could be used to guide the opam-repository policy that the apk repo should be tagged @edgecommunity - e.g. checking the list of installed repos and identifying the tag. This has has the benefit that the policy lives with the opam-repository, rather than in the opam-client. These tests could start out in conf-capnproto (given that there's only one package using it) but be spun into conf-alpine-edgecommunity if others come along. A similar trick could be deployed for EPEL detection (although we still the support in opam for suggesting that the repo needs enabling first).

[dra27]

The 2.1 issue is solved (allowing correct detection of these packages) - additional issues opened to track the remaining two items.