DRAFT: archival process, x-maintenance-run on Dec 9th, scheduled to merge on January 1st 2026

[hannesm]

If you would like to preserve a package, please don't hesitate to comment here. Please include the package name and version, and also where it is used. Thanks a lot.

See the announcement at https://discuss.ocaml.org/t/opam-repository-archival-next-run-scheduled-2026-01-01

[hannesm]

force-pushed after #28065 (comment) made it clear that we should keep dune. I hardcoded dune in the maintenance-intent-filter tool to avoid any removal thereof in the future.

[WardBrian]

I'd like to request to maintain availability for:

core versions v0.16.0 and v0.16.1

These are used by https://github.com/stan-dev/stanc3 while it still builds with OCaml 4.14.
I can be contacted at: bward <AT> flatironinstitute.org

It's possible I may need to request more packages -- nothing immediately stands out on the list, but I cannot truly verify this until I can run builds, which I cannot without core at these versions.

[hannesm]

@WardBrian re-added in 1232bb2

[WardBrian]

Thanks @hannesm.

I am getting further failures, currently because of ppx_expect. The 0.16.2 version being left behind has an available: constraint that 16.0 and 16.1 do not, which means that preserving 16.1 (or removing that constraint on 16.2, as was done in #27519) is important for installability on 32bit targets. I suspect the other packages touched in #27519 will also be affected if they've had more recent patch releases.

[WardBrian]

Going through the announcement and #27519, there is the following overlap, meaning that these packages would no longer be installable (for this major version) on 32 bit arm after this archiving:

bin_prot v0.17.0
ppx_expect v0.16.1

So not too bad. It's an equally good idea to either keep these packages or remove the available: clause on the version in this series that is being kept

There are obvious a lot of other JS packages that could be impacted if even more minor versions in the 0.16 or 0.17 series got archived down the line

[hannesm]

Ouch, this is really bad. Thanks for your investigations.

I pushed f8bfc85 which puts ppx_expect 0.16.0 and 0.16.1 back here.

About bin_prot, looking at the diff between 0.17.0 and 0.17.0-1, I don't understand how this would influence arm32 availability. Could you confirm?

Generally speaking, indeed the tooling to evaluate what could be archived uses thousands of solving steps (across the supported OCaml compiler versions), already using ~100 CPU hours. But it only uses x86_64 on linux (debian-10) into account. I guess it should solve even more things, varying the cpu architecture and the OS. Maybe that is a good question for the opam-repository maintainers, which architectures and OS they consider supported. Obviously this tooling hardly becomes manageable if it takes days to run. Suggestions which architectures and OS are crucial are highly welcome.

[hannesm]

About "modifying the available: of existing opam packages": I'm not keen to do that, since I do not know any internals and why the author(s) decided to mark something as unavailable on a specific platform. About arm32 (and x86_32) especially, my guess is that since OCaml doesn't provide a native backend anymore, the availability of packages is dropping there. At least I personally don't bother fixing 32 bit issues if it takes more than 5 minutes, since I don't have any test machine(s) at hand.

[kit-ty-kate]

The archiving documentation states:

The package version's maintainers will be notified of the intent to archive.

however, as maintainer of some of the packages being scheduled to archive here i haven't been notified. Is that meant to happen later?

[hannesm]

The archiving documentation states:

The package version's maintainers will be notified of the intent to archive.

however, as maintainer of some of the packages being scheduled to archive here i haven't been notified. Is that meant to happen later?

Thanks for your valuable feedback. Indeed, this is a multi-step approach here:

• 1. prepare the set of packages
• 2. ask people who care and have external utilities / private developments (see the announcement on discuss)
• 3. once settled with ii (which may re-add some packages), still 2 weeks before the scheduled archival date, ping maintainers
• 4. once settled, merge the PR

I understand that we haven't always stick to the agenda in the past. I do appreciate your feedback, and will stick to the above process (expect the maintainer ping early next week).

[WardBrian]

About bin_prot, looking at the diff between 0.17.0 and 0.17.0-1, I don't understand how this would influence arm32 availability. Could you confirm?

It appears 0.17.0-1 was prepared by someone outside JS, so they didn't re-add the prohibition on arm32. So yes, it is fine, my mistake.

About arm32 (and x86_32) especially, my guess is that since OCaml doesn't provide a native backend anymore, the availability of packages is dropping there. At least I personally don't bother fixing 32 bit issues if it takes more than 5 minutes, since I don't have any test machine(s) at hand.

Yes. My understanding from a discussion with one of the JS devs is that this is basically why they introduced those bounds -- there is at least one known bug on 32bit targets that they don't intend to fix, so they mark it as unavailable.

I personally think this is the wrong course of action, mostly because it is impossible for a downstream user to even install/test if they would actually be affected by such bugs when an available clause is in place. For my particular package, when those clauses are removed, our rather large test suite passes on those targets, so I'm content to continue distributing those binaries on a best-effort basis, so long as I can keep the dependencies installable...

I looked into ocaml/opam#5283 or some other feature to allow end users to say 'actually, trust me on this one', but frankly couldn't find a good way to slice through that part of the opam code.

[kit-ty-kate]

I looked into ocaml/opam#5283 or some other feature to allow end users to say 'actually, trust me on this one', but frankly couldn't find a good way to slice through that part of the opam code.

I replied on ocaml/opam#5283 with the common workaround if that can be of use to you

[hannesm]

Closing this PR, as it needs further discussion about the policy / process.

But there are 2 PRs for less controversial archives:

• Archive available: false packages #29360 archives all available: false packages
• archival of packages with x-maintenance-intent none #29363 does the archival run of the x-maintenance-intent: [ "(none)" ] OR x-maintained: false packages (still keeping those in the repository needed by other packages to avoid that something is uninstallable