[CentOS-devel] RFC: OCaml SIG

Jon Ludlam

jonathan.ludlam at citrix.com
Thu Dec 11 13:07:10 UTC 2014


On Thu, Dec 11, 2014 at 07:38:36AM +0100, Honza Horak wrote:
> On 12/10/2014 07:47 PM, Jon Ludlam wrote:
> >>* 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.
> 
> Ok, the hash may help in this case to avoid a false package is
> installed. But isn't it still possible someone asks for just
> unversioned provide (e.g. 'ocaml(Text)') and expects non-SCL package
> to be installed?
> 

I don't believe anyone would or should ever do that. The requires
lines of the form "ocaml(...)" are generated automatically. Explicit
dependencies in the spec file should be depending on the RPM package
name rather than a particular module name that's being provided, and
the RPM package names _will_ have the {?scl_prefix} before them. 
Perhaps the easiest thing to do is to see whether any packages do
this already?

Also, there is some related interesting discussion on BZ ticket here:
https://bugzilla.redhat.com/show_bug.cgi?id=460872

Jon



More information about the CentOS-devel mailing list