On Thu, Jun 25, 2020 at 12:15:51PM +0200, Dan Čermák wrote:
> "Richard W.M. Jones" <rjones@xxxxxxxxxx> writes:
>
> >> Maybe I should do COPR builds of all this so everybody can easily see
> >> what I'm talking about? I did a total of 63 package builds in mock,
> >> many of them simple rebuilds, so it will take a little time to get
> >> that going. Do we know yet what the timeframe is for an ocaml 4.11
> >> release?
> >
> > This is all great stuff, and I think it also makes me wonder how we
> > can make OCaml packaging simpler in Fedora.
> >
> > RPM has a new %generate_buildrequires feature which we might utilise
> > (driven from the opam package metadata, I guess?). I would also like
> > to drop the whole ocaml-pkg vs ocaml-pkg-devel split, it's confusing
> > and not necessary. And maybe we could look at some kind of opam2spec
> > scripting, similar to cpanspec. Of course the devil is in the details
> > because unless we can mostly automate packaging, we could end up with
> > something that's even more complicated to deal with the exceptional
> > cases.
>
> Thanks for bringing this up Rich, I was actually thinking about this for
> quite a while now after getting involved in OCaml packaging a bit.
>
> I would suggest the following: we introduce a new Provides for ocaml
> packages: Opam($pkg-name) = 1.2.3
> I would propose that the ocaml provides generator takes care of adding
> this to the devel package. This shouldn't be really hard to pull off, it
> would just need to find the opam file and grep for the version.
Does it need "Opam()", surely ocaml-${pkg-name} is sufficient?
(unless $pkg-name == ocaml in which case we special-case it)
> %generate_buildrequires could be used to parse the opam file from the
> tarball and extract the dependent opam packages from the depends:
> array. E.g. the following:
> --8<---------------cut here---------------start------------->8---
> depends: [
> "ocaml" {>= "4.04.2"}
> "base" {>= "v0.13" & < "v0.14"}
> "dune" {>= "1.5.1"}
> ]
> --8<---------------cut here---------------end--------------->8---
> would translate to:
> --8<---------------cut here---------------start------------->8---
> BuildRequires: Opam(ocaml) >= 4.04.2
> BuildRequires: Opam(base) >= 0.13 and Opam(base) < 0.14
> BuildRequires: Opam(dune) >= 1.5.1
> --8<---------------cut here---------------end--------------->8---
Agreed, if Opam() was replaced with ocaml-
> The hypothetical opam2spec would be certainly also a huge improvement,
> as I think that most ocaml packages could be completely autogenerated.
>
> But as you already said, the devil is most likely in the details, so
> maybe we should start collecting ideas and potential pitfalls first? I
> have therefore also cc'd Olaf, who takes care of Ocaml in
> openSUSE. I would hope that we can coordinate our efforts, as Olaf has
> some pretty nice ocaml macros that automatically generate file lists for
> the subpackages (thereby already simplifying packaging quite a bit).
>
> And at last I'd like to throw in a (probably quite controversial) idea:
> how about we move ocaml into a module? Not to be able to have multiple
> ocaml versions as streams, but so that we can use MBS to automatically
> untangle the bootstrap loops for us. I was totally not aware of this
> feature of MBS, but it was mentioned by Stephen in this email:
> https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/NY7RTBTCHF2IVWMWJ6JG2RQZVW5EZDRB/
I think I've suffered enough from having to deal with the virt module
in RHEL without having more modularity in my life. In any case MBS
doesn't actually solve dependencies (in virt:rhel we have to list them
all explicitly, which is even worse than the current situation), and
I've already solved the dependency problem properly in my goals script.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
