[CentOS-devel] RFC: OCaml SIG

[Jon Ludlam]

On Wed, Dec 10, 2014 at 07:02:01PM +0100, Honza Horak wrote:
> On 12/09/2014 12:10 AM, Jim Perrin wrote:
> >
> >
> >On 12/08/2014 04:52 PM, Jon Ludlam wrote:
> >
> >>
> >>I've had a go at making an SCL of the latest OCaml release, which
> >>seems to be working OK so far. I'd quite like to get some feedback,
> >>to see if I'm going about things the right way. The SPECS and
> >>SOURCES are on github: https://github.com/jonludlam/ocaml4021-buildroot
> >>and I've been building for CentOS 7 and 6 on copr:
> >>https://copr.fedoraproject.org/coprs/jonludlam/ocaml4021/
> >>
> >>Comments and bug reports very welcome!
> 
> Hi Jon,
> 
> great to see a new SCL, good work! I have couple of notes for
> consideration..
> 
> * the collection name looks like it includes minor version of ocaml
> as well; might be correct, depending on ocaml versioning policy, but
> generally the version should only use the part of the version that
> likely changes if some incompatible change comes -- thus e.g. for
> python we only use two numbers (python27), not three (python274),
> since the latest bugfix release do not include incompatible changes
> and we can update them
>

Makes sense - I'll double check what the upstream policy is on
numbers and then likely change it.
 
> * then I see couple of provides that do not include scl version,
> e.g.: ocaml(Ssl_threads) = 9925dd2c278261461f67ee0f74f4149a
> I guess it means that some non-SCL ocaml package could be satisfied
> with SCL package, which doesn't feel right. We rather require
> sclname in all provides somehow
> 

Hmm, this is interesting. The requires/prodides are (almost) all
generated, and they are extremely brittle. The fedora packaging wiki
mentions here (https://fedoraproject.org/wiki/Packaging:OCaml) that
OCaml "OCaml does not offer binary compatibility between releases of
the compiler (even between bugfixes)", and that this mechanism
"enforces the same requirements as the OCaml linker itself". I _think_
the likelihood of a collision between an SCL and non-SCL package is
almost certainly zero, but I should investigate this a bit more.

Thanks for the feedback!

Jon

> Honza
> 
> >
> >Excellent! We're working out the details for getting the scl.org folks
> >set up. Once we have the basics in place, it would be great to have this
> >pulled in. In the mean time, we can certainly kick the packages around a
> >bit. Thanks very much for this.
> >
> >
>