Opam repository archival, Phase 1: unavailable packages

It’s done. It’s done. It’s done.

Happy new year!

We just merged the removal of the above mentioned uninstallable packages from opam-repository. In case you want to get these old opam files, please use:

opam repository add opam-archive https://github.com/ocaml/opam-repository-archive.git

Each of the opam files now include the two additional fields: (a) a x-reason-for-archival and (b) an x-opam-repository-commit-hash-at-time-of-archiving (as described in opam-repository/governance/policies/archiving.md at master · ocaml/opam-repository · GitHub).

We also pushed the tag ‘2025-01-before-archiving-phase1’ to the main opam-repository.

Statistics of opam files and unique packages

date (January 1st) opam files unique packages
phase1 28863 4805
2025 33033 4973
2024 29942 4572
2023 25983 4126
2022 21418 3647
2021 16632 3156
2020 12998 2554
2019 10236 2192
2018 8110 1878
2017 5966 1458
2016 4308 1086
2015 3081 823
2014 1856 593
2013 485 486

This shows that the amount of opam files are now back to mid-2023, while in the unique packages we’re in mid-2024.

Next steps

Next steps and call to action:

  • by January 15th we’ll have a list of packages that require OCaml < 4.08 (plus those packages that were marked unavailable between December 15th and January 15th)
  • please mark your packages with x-maintenance-intent or flags: deprecated

On February 15th we will propose a list of packages that are deprecated or do not fall into the x-maintenance-intent - but only if there’s no reverse dependency that requires them: if the package “cohttp” is marked with x-maintenance-intent: "(latest)", and some other package “bar” requires a specific cohttp version (‘depends: “cohttp” {= “1.2.3”}’), the “cohttp.1.2.3” will be kept (to avoid making “bar” uninstallable).

We plan to have tooling ready that allows to spot which packages would be beneficial to have a x-maintenance-intent or flags: deprecated (i.e. which ones would allow to archive more packages).

What is the difference between flags: deprecated and x-maintenance-intent?
Please use flags: deprecated if either specific versions or an entire package should be archived. Please use x-maintenance-intent for packages that are actively developed.

If you have any further questions, please don’t hesitate to ask.

10 Likes