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

[Martin Lucina <martin@xxxxxxxxxx>]

On Monday, 27.08.2018 at 18:00, Hannes Mehnert wrote:
> hey,
> 
> On 27/08/2018 16:38, Martin Lucina wrote:
> > On Friday, 24.08.2018 at 19:05, Hannes Mehnert wrote:
> >> sounds about right!
> > 
> > Your reply did not go to the list, adding it back in Cc:.
> 
> oh, sorry.
> 
> >> On 24/08/2018 16:57, Martin Lucina wrote:
> >> in the mirage utility itself, there are various references to
> >> solo5-kernel-* which need adjustment
> > 
> > Yes, I'll do those.
> > 
> > However, I'm not sure that just making ocaml-freestanding and mirage-solo5
> > depend on the new solo5-bindings-* packages instead of solo5-kernel-* is
> > sufficient. Having just experimented with some pins, this can result in a
> > situation where (e.g. if downgrading via a pin) ocaml-freestanding and
> > mirage-solo5 get out of sync.
> > 
> > I'm not sure what the best way to prevent that happening is. Making
> > mirage-solo5 (the new 0.4.0+) conflict with solo5-kernel-* and mirage-solo5
> > (all currently published versions) conflict with solo5-bindings-* seems
> > like a rather roundabout way to accomplish this?
> 
> that sounds fine to me.

Should I also do this for ocaml-freestanding? i.e. make the published
versions (< 0.4.0) conflict with the new Solo5 package names and the new
0.4.0 conflict with the old Solo5 package names?

Thinking about it, I'm not sure this will solve anything in practice, since
the version of the mirage frontend is not expressed anywhere. So, if
someone does an "opam update && opam upgrade" and then decides they want to
go back to the older release, they'd need to additionally pin the last
version of mirage that works with mirage-solo5 0.3.0.

Perhaps I shouldn't try to solve this case (downgrading to a previous
release) at all?

-mato

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