[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Merge of opam-overlays and mirage-opam-overlays


  • To: mirageos-devel@xxxxxxxxxxxxxxxxxxxx
  • From: Kate <kit-ty-kate@xxxxxx>
  • Date: Mon, 13 Jul 2026 23:53:30 +0100
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=key1 header.d=exn.st header.i="@exn.st" header.h="From:Subject:Date:Message-ID:To:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References"
  • Delivery-date: Mon, 13 Jul 2026 22:53:50 +0000
  • List-id: Developer list for MirageOS <mirageos-devel.lists.xenproject.org>

Thanks,

Would you be able to open a ticket on our bugtracker for the redirect issue?

https://github.com/ocaml/opam/issues

For the uncaught exception i'm gonna blame it on my setup because i can't reproduce it.

Cheers,
Kate

On 7/13/26 13:29, Virgile Robles wrote:
Hi Kate,

Thanks for the report. Locally I never encountered any exceptions,
however I realize that my tests never checked that the redirection
worked (I tested having only opam-overlays or
opam-overlays+mirage-opam-overlays), since I expected any user of
mirage-opam-overlays to have opam-overlays added as well.

And indeed opam doesn't seem to follow the redirect and I couldn't find
a way to make it work.

For now I've re-added the packages to mirage-opam-overlays, which is the
safer option (they are still in opam-overlays, and mirage-opam-overlays
is still deprecated).

Does that solve the issue you were seeing?

Cheers,
Virgile

Le 11/07/2026 à 19:58, Kate a écrit :
Hi,

Locally, the first time i called opam update, this repository failed
with some uncaught exception and even after non-failed subsequent
updates the resulting repository wasn't the one it's supposed to be
redirected to, thus leaving us with the empty repository.

Could you confirm the redirection worked for you locally when you tested
this?


Cheers,
Kate

On 7/8/26 17:18, Virgile Robles wrote:
Dear all,

Today our build infrastructure based on opam-monorepo is relying on
all unikernel dependencies building with dune. To that end, we have
two opam overlay repositories containing ports of packages that do not
use dune upstream:

   * opam-overlays <https://github.com/dune-universe/opam-overlays>:
     historically decoupled from Mirage, containing almost all ports
     guaranteed to build with dune but not necessarily cross-compilable
   * mirage-opam-overlays <https://github.com/dune-universe/mirage-opam-
     overlays>: for ports that need further or different adaptations to
     be cross-compilable, since we need it for Mirage.

The second one actually only contains the zarith package, for which we
have two different ports.

Following some discussions we had some time ago observing there is
some seemingly unnecessary complexity in having two separate
repositories for one single package, and that opam-monorepo is (to my
knowledge) only used by Mirage, I have merged mirage-opam-overlays
into opam-overlays and propose that going forward only opam-overlays
be used (and requires that all ports are cross-compilable).

mirage-opam-overlays is now empty and redirecting to opam-overlays, so
no unikernels should be affected, but I'm ready to revert if this
change broke someone's workflow (Mirage-related or not), so please let
me know if this is the case or if you have a use for the non-mirage
zarith port!

After some time in the absence of issues I'll submit a PR to mirage/
mirage to produce Makefiles without mirage-opam-overlays.

Have a great day,

Virgile









 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.