-
Notifications
You must be signed in to change notification settings - Fork 27
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
Semantically equivalent but different "dev-repo" fields lead to build errors #118
Labels
bug
Something isn't working
requires dune change
Would need additional dune features to implement
upstream
Fix has to be implemented upstream
Comments
Leonidas-from-XIV
added
the
requires dune change
Would need additional dune features to implement
label
Dec 23, 2022
Leonidas-from-XIV
added
requires dune change
Would need additional dune features to implement
and removed
requires dune change
Would need additional dune features to implement
labels
Dec 23, 2022
Hi @TheLortex, sorry for coming back to this issue so late. I've opened #365 as a workaround to catch this particular case, but for a nice solution it would be best if we could just just unpack one tarball per dependency (so I added the |
tmattio
added
bug
Something isn't working
upstream
Fix has to be implemented upstream
labels
Jan 10, 2023
Leonidas-from-XIV
added a commit
to Leonidas-from-XIV/opam-repository
that referenced
this issue
May 3, 2023
CHANGES: ### Added - Display warning when a package to be locked is missing a `dev-repo` field and is being skipped because of it (tarides/opam-monorepo#341, tarides/opam-monorepo#362, @kit-ty-kate, @Leonidas-from-XIV) - Add option `--keep-symlinked-dir` to preserve symlinks in `duniverse/`, which can be useful for local development. (tarides/opam-monorepo#348, tarides/opam-monorepo#366, @hannesm, @Leonidas-from-XIV) ### Changed - Canonicalize the URLs of the OPAM `dev-repo` fields to be able to detect more semantically equivalent URLs, this should reduce the risk of build failures due to duplicate code pulled (tarides/opam-monorepo#118, tarides/opam-monorepo#365 @TheLortex, @Leonidas-from-XIV) - Simple the error message printed when dependencies don't use dune as their build system. The opam-0install diagnostic message is no longer printed in this case and the message has been reformatted and reworded to make the salient information easier to see. (tarides/opam-monorepo#384, @gridbugs) ### Fixed - Error in case where multiple packages with different dev-repo fields would be placed in the same duniverse directory (tarides/opam-monorepo#377, @gridbugs) - Fix a failure when using opam-monorepo with an opam 2.2 root (tarides/opam-monorepo#379, @kit-ty-kate) - Fix assertion failure when prefix of "lock" subcommand is used (tarides/opam-monorepo#381, @gridbugs) - Treat packages without build commands as virtual only if also lack install commands, as some non-virtual packages might only have install commands. (tarides/opam-monorepo#376 @Leonidas-from-XIV, @gridbugs)
Leonidas-from-XIV
added a commit
to Leonidas-from-XIV/opam-repository
that referenced
this issue
Sep 11, 2023
CHANGES: ### Added - Display warning when a package to be locked is missing a `dev-repo` field and is being skipped because of it (tarides/opam-monorepo#341, tarides/opam-monorepo#362, @kit-ty-kate, @Leonidas-from-XIV) - Add option `--keep-symlinked-dir` to preserve symlinks in `duniverse/`, which can be useful for local development. (tarides/opam-monorepo#348, tarides/opam-monorepo#366, @hannesm, @Leonidas-from-XIV) - Adopt the OCaml Code of Conduct (tarides/opam-monorepo#391, @rikusilvola) - Add solver tests (tarides/opam-monorepo#394, @samoht) ### Changed - Canonicalize the URLs of the OPAM `dev-repo` fields to be able to detect more semantically equivalent URLs, this should reduce the risk of build failures due to duplicate code pulled (tarides/opam-monorepo#118, tarides/opam-monorepo#365 @TheLortex, @Leonidas-from-XIV) - Simple the error message printed when dependencies don't use dune as their build system. The opam-0install diagnostic message is no longer printed in this case and the message has been reformatted and reworded to make the salient information easier to see. (tarides/opam-monorepo#384, @gridbugs) - Encode `dev-repo` constraints in the opam solver - this allows to resolve more involved version constraints that were failing before (tarides/opam-monorepo#396, @samoht) ### Deprecated ### Fixed - Error in case where multiple packages with different dev-repo fields would be placed in the same duniverse directory (tarides/opam-monorepo#377, @gridbugs) - Fix a failure when using opam-monorepo with an opam 2.2 root (tarides/opam-monorepo#379, @kit-ty-kate) - Fix assertion failure when prefix of "lock" subcommand is used (tarides/opam-monorepo#381, @gridbugs) - Treat packages without build commands as virtual only if also lack install commands, as some non-virtual packages might only have install commands. (tarides/opam-monorepo#376 @Leonidas-from-XIV, @gridbugs) - Improve the ordering of package candidates by putting broken packages at then end of the list (tarides/opam-monorepo#395, tarides/opam-monorepo#397, @samoht) ### Removed ### Security
Leonidas-from-XIV
added a commit
to Leonidas-from-XIV/opam-repository
that referenced
this issue
Sep 11, 2023
CHANGES: ### Added - Display warning when a package to be locked is missing a `dev-repo` field and is being skipped because of it (tarides/opam-monorepo#341, tarides/opam-monorepo#362, @kit-ty-kate, @Leonidas-from-XIV) - Add option `--keep-symlinked-dir` to preserve symlinks in `duniverse/`, which can be useful for local development. (tarides/opam-monorepo#348, tarides/opam-monorepo#366, @hannesm, @Leonidas-from-XIV) - Adopt the OCaml Code of Conduct (tarides/opam-monorepo#391, @rikusilvola) - Add solver tests (tarides/opam-monorepo#394, @samoht) ### Changed - Canonicalize the URLs of the OPAM `dev-repo` fields to be able to detect more semantically equivalent URLs, this should reduce the risk of build failures due to duplicate code pulled (tarides/opam-monorepo#118, tarides/opam-monorepo#365 @TheLortex, @Leonidas-from-XIV) - Simple the error message printed when dependencies don't use dune as their build system. The opam-0install diagnostic message is no longer printed in this case and the message has been reformatted and reworded to make the salient information easier to see. (tarides/opam-monorepo#384, @gridbugs) - Encode `dev-repo` constraints in the opam solver - this allows to resolve more involved version constraints that were failing before (tarides/opam-monorepo#396, @samoht) ### Deprecated ### Fixed - Error in case where multiple packages with different dev-repo fields would be placed in the same duniverse directory (tarides/opam-monorepo#377, @gridbugs) - Fix a failure when using opam-monorepo with an opam 2.2 root (tarides/opam-monorepo#379, @kit-ty-kate) - Fix assertion failure when prefix of "lock" subcommand is used (tarides/opam-monorepo#381, @gridbugs) - Treat packages without build commands as virtual only if also lack install commands, as some non-virtual packages might only have install commands. (tarides/opam-monorepo#376 @Leonidas-from-XIV, @gridbugs) - Improve the ordering of package candidates by putting broken packages at then end of the list (tarides/opam-monorepo#395, tarides/opam-monorepo#397, @samoht) ### Removed ### Security
nberth
pushed a commit
to nberth/opam-repository
that referenced
this issue
Jun 18, 2024
CHANGES: ### Added - Display warning when a package to be locked is missing a `dev-repo` field and is being skipped because of it (tarides/opam-monorepo#341, tarides/opam-monorepo#362, @kit-ty-kate, @Leonidas-from-XIV) - Add option `--keep-symlinked-dir` to preserve symlinks in `duniverse/`, which can be useful for local development. (tarides/opam-monorepo#348, tarides/opam-monorepo#366, @hannesm, @Leonidas-from-XIV) - Adopt the OCaml Code of Conduct (tarides/opam-monorepo#391, @rikusilvola) - Add solver tests (tarides/opam-monorepo#394, @samoht) ### Changed - Canonicalize the URLs of the OPAM `dev-repo` fields to be able to detect more semantically equivalent URLs, this should reduce the risk of build failures due to duplicate code pulled (tarides/opam-monorepo#118, tarides/opam-monorepo#365 @TheLortex, @Leonidas-from-XIV) - Simple the error message printed when dependencies don't use dune as their build system. The opam-0install diagnostic message is no longer printed in this case and the message has been reformatted and reworded to make the salient information easier to see. (tarides/opam-monorepo#384, @gridbugs) - Encode `dev-repo` constraints in the opam solver - this allows to resolve more involved version constraints that were failing before (tarides/opam-monorepo#396, @samoht) ### Deprecated ### Fixed - Error in case where multiple packages with different dev-repo fields would be placed in the same duniverse directory (tarides/opam-monorepo#377, @gridbugs) - Fix a failure when using opam-monorepo with an opam 2.2 root (tarides/opam-monorepo#379, @kit-ty-kate) - Fix assertion failure when prefix of "lock" subcommand is used (tarides/opam-monorepo#381, @gridbugs) - Treat packages without build commands as virtual only if also lack install commands, as some non-virtual packages might only have install commands. (tarides/opam-monorepo#376 @Leonidas-from-XIV, @gridbugs) - Improve the ordering of package candidates by putting broken packages at then end of the list (tarides/opam-monorepo#395, tarides/opam-monorepo#397, @samoht) ### Removed ### Security
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
bug
Something isn't working
requires dune change
Would need additional dune features to implement
upstream
Fix has to be implemented upstream
The packages
mirage-clock
andmirage-clock-freestanding
are provided by the same repository but theirdev-repo
fields are different:git://github.com/mirage/mirage-clock
andgit+https://github.com/mirage/mirage-clock.git
.This causes duniverse to download the mirage-clock repo twice under different names, leading to a build error further on are some packages are defined twice.
The text was updated successfully, but these errors were encountered: