-
Notifications
You must be signed in to change notification settings - Fork 0
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
done with archive-opam #2
Conversation
174fceb
to
2d0aa92
Compare
This comment was marked as outdated.
This comment was marked as outdated.
2d0aa92
to
c11482d
Compare
This comment was marked as outdated.
This comment was marked as outdated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
c11482d
to
98e2d4f
Compare
This comment was marked as outdated.
This comment was marked as outdated.
Thanks a lot. I think it’s almost there. Can we prevent removing the comments, as in avoiding things like -available: false # uses a git url, no checksum. newer versions exist
+available: false I hope that will not be a pain 🙏 The diff file is super useful, thanks again |
@mseri thanks for the suggestion, unfortunately, the opam-file-format package with the opam file parser does not preserve comments. While I see that it'd be great, it'd need adjustments to opam-file-format (and eventually opam itself). not sure whether it is worth it. I'll take a brief look into |
98e2d4f
to
7daa6d0
Compare
I force-pushed another commit, now with a hacked up archive-opam preserving any comment on the last line. As usual, the diff: |
This comment was marked as off-topic.
This comment was marked as off-topic.
As mentioned in ocaml/opam#6335, you shouldn't use |
This comment was marked as outdated.
This comment was marked as outdated.
Thanks for doing this. In my opinion it would make sense to move these packages alongside the How hard/computationally-expensive would it be to have a tool (or extend opam admin check) to attach the reason of the uninstallability to the opam file? Say as a comment at the end of the file or as a separate log file? |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
Wow, this list is really useful with those explanations attached, @hannesm! For example, I could see that we might be able to fix vchan-unix by fixing vchan. OTOH, I would also be fine with moving all these enmass to the archive repository, and letting interested maintainers propose them back to the mainline opam-repo once they're fixed. We also need to restore the "uninstallability" check to the opam-repo-ci don't we? That got dropped for some reason a few years ago, but it's necessary to make sure that any new constraint changes don't make existing packages uninstallable. |
Ok, another try. Please disregard the above output. This one is better:
What we can for sure fix: dune-rpc-lwt.3.0.3, utop.1.6, opam-core.2.0.0~rc |
and to add to the list above:
the only thing is ocaml-option-spacetime -- a dead package that has been introduced for the future --let's leave it as is ;) |
The story about vchan-* is:
So, it turns out the "leftovers", vchan-unix < 4.0.2 and vchan-xen < 4.0.2, are still in the opam-repository, but not installable.
YES
Indeed, we talked about this yesterday in the opam-repository meeting. There's an issue open ocurrent/opam-repo-ci#118 |
And now, the second set (481 that depended on the uninstallable ones):
I'm pretty sure there isn't yet a fixpoint reached, but will need to have a break from opam-repo-archive. |
thanks for discussions, closing this in favour of the real one [tm] for phase 1. if you have any open comments/suggestions, please get in touch. |
this is a draft.