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.