Re: [MirageOS-devel] Solo5 renaming and OPAM package names

[Martin Lucina <martin@xxxxxxxxxx>]

All,

progress update on this:

After spending a couple of days writing a bunch of OPAM-repository-munging
tools, so that I never again have to do 20+ changes to packages manually,
I've finally done an end-to-end test of the changes with Mirage, using my
wip-renaming branch of the opam-solo5 repository:
https://github.com/mato/opam-solo5/tree/wip-renaming.

Note that this does not actually work yet without manual hacks due to some
issues I found with the Solo5 changes (see the Solo5 PR #272 for details).

Apart from the issues mentioned there, there are a couple more that are
Mirage and/or OPAM specific:

1. Here is what happens when I add that repository and attempt to upgrade
an existing Mirage/Solo5 switch:

---cut here---
$ opam upgrade
The following packages are not being upgraded because the new versions conflict
with other installed packages:
  - mirage.dev~solo5
  - mirage-solo5.dev~solo5
  - ocaml-freestanding.dev~solo5
  - opam-core.2.0.0
  - opam-file-format.2.0.0
    ∗ opam-ed.0.1 is installed and requires opam-file-format = 2.0.0~beta3
  - opam-format.2.0.0
However, you may "opam upgrade" these packages explicitly, which will ask
permission to downgrade or uninstall the conflicting packages.
Nothing to do.
$ opam upgrade mirage
The following actions will be performed:
  ↗ upgrade   mirage               3.1.1 to dev~solo5
  ∗ install   solo5-bindings-vt    dev~solo5
          [required by ocaml-freestanding]
  ⊘ remove    solo5-kernel-ukvm    0.3.1
          [conflicts with ocaml-freestanding]
  ↗ upgrade   ocaml-freestanding   0.3.1 to dev~solo5
  ↗ upgrade   mirage-solo5         0.3.0 to dev~solo5 [uses ocaml-freestanding]
  ↻ recompile mirage-bootvar-solo5 0.3.0              [uses mirage-solo5]
===== ∗ 1   ↻ 1   ↗ 3   ⊘ 1 =====
Do you want to continue? [Y/n] n
---cut here---

Q: People will need to explcitly "opam upgrade mirage" to get
the new version. Is this OK?

2. "mirage clean" fails after upgrading due to ocamlbuild complaining about
_build_ukvm (which it now knows nothing about). So, I guess at least for
the "clean" phase, we should keep those old names around so that this does
not fail?

Lastly, on yesterday's mirage call, someone (ThomasG?) suggested using
'hvt' rather than just 'vt' for naming the target formerly known as 'ukvm'.
Given that I'll have to redo this patch set anyway, I'm considering taking
that suggestion, since it is both more explicit ("*hardware*
virtualization") and lexicographically more distinct from another target
('virtio').

Any objections?

Thanks,

-mato

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/mirageos-devel