-
Notifications
You must be signed in to change notification settings - Fork 292
[maintenance]: clock doesn't need to be an external package #5883
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Signed-off-by: Edwin Török <edwin.torok@cloud.com>
Is that command using the metadata in xen-api or xs-opam? |
The opam command uses the metadata that is available locally to find out the dependencies and uses the remote metadata to install them, I think that is why it fails (or it doesn't know what the version of clock is locally, it probably won't be master, but ~dev). |
I just created a new switch to test this, it worked outright:
Please check that the xs-opam repository is the only one used in the switch and is up-todate |
I also added --with-test, maybe that is the difference? |
I can try with Tried with your original command after emptying the opam switch, it's able to resolve all the packages and offers to install them |
Trying to set up a build on Fedora40 on an empty opam switch fails:
(I could
opam pin add
, but I prefer not to, because then you get all the problems with 'master' version changing without opam knowing about it).However it is not required for 'clock' to be a public library. Sure if you remove public_name it complains that you cannot have a private library as a dependency of a public package.
But you can just add a '(package)' field to the library and say which already existing public package you want it to be a part of and then it all works (I think this is a somewhat recent Dune feature).
Draft PR because I haven't checked whether this builds in Koji, but it works in opam.