Question: When it is OK to remove some packages' versions from opam?

Community
1

I’m maintainer of a few packages. Some old versions of these packages have become uninstallable because of changes in reverse dependencies. The fixes have created new versions of my packages and these new versions are very compilable.

This broken package versions:

  1. are broken in all compilers
  2. are not dependencies of any other packages

Is it OK to remove broken versions from opam entirely?

1 Like
2

remark on this discussion about immutable packages / lockfiles: rust
also has the concept of “yanked” crates, which if I understand correctly
is used for annotating versions of packages that you can still use if they’re in
your lockfile (so building a program still works) but will be ignored by
dependency resolution. In this case you wouldn’t ever remove a
package, just yank them.

2 Likes
3

If we will recall that the opam repository is actually a Git repository, then even “entirely removed” package could be always installed by a determined user. Therefore, the impact of the removal is not that severe.

On the other hand, at some point of time those packages were definitely installable, so instead of removing it, a proper constraining might help (even if it is an overconstraint).

Finally, with these taken into account, it is better to remove a totally broken package, than keep it polluting the opam universe. However, I think that it should be a responsibility (totally automated1) of an opam-repository administrators to prune the old packages, after issuing several warnings.

1) However, in general it is hard to automatically decide whether a package is installable, i.e., whether exists a configuration in which package is buildable, especially in the presence of system dependencies. And many packages are merged into the opam repository without passing CI, for example BAP never passed opam-repository’s CI, for various reasons, but definitely not because it is not installable.

1 Like
4

Thanks, @ivg. It seems that removing broken package version is a way to go.

5

My preferred approach to this question is to edit the opam package description with

available: [false]

This makes it impossible for new users to install the package, but the metadata is still there so (1) it’s easy to inspect the metadata for this version (if I’m debugging an old opam file that specifies it as a dependency, at least I can find it easily without having to crawl the git history of the opam-repo) and (2) determined users can use opam pin edit <package.version> to remove this restriction and pin it locally.

4 Likes