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