[Fedora-packaging] MinGW subpackages of OCaml packages

[Richard W.M. Jones]

On Tue, Dec 09, 2008 at 10:46:08AM -0800, Toshio Kuratomi wrote:
> Richard W.M. Jones wrote:
> 
> > OK, this is fair too.  I usually encourage OCaml packagers to start
> > out with:
> > 
> > http://fedoraproject.org/wiki/Image:Packaging_OCaml_ocaml-foolib.spec
> > 
> > linked from:
> > 
> > http://fedoraproject.org/wiki/Packaging/OCaml
> > 
> > That doesn't currently include a mingw subpackage, and nor should it.
> > 
> > Note that there are currently 70 OCaml packages in Fedora, and only a
> > handful of those (10) were proposed to be cross-compiled, 2 of those
> > being the cross-compiler itself.
> > 
> So.. I'd like to stick with the current Guidelines that require separate
> reviews and packages for cross-compiled packages.  Here's some of the logic:
> 
> 1) Just because you are the maintainer of the package now doesn't mean
> that you'll be the maintainer in Fedora 27.
> 
> 2) Rather than special-case OCaml, (or really... the OCaml subset
> maintained by you) it would be better to write a general rule.  However,
> that general rule leads to a bit of confusion -- subpackages may be used
> when the maintainer is amenable to it.  Separate packages when the
> maintainer is not.  And when maintainership switches, go with whatever
> was done before?  Or merge and drop as the current maintainer wishes?
> This is all very ugly.
> 
> 3) Since we currently review packages on import time (instead of having
> an ongoing re-review process) and cross-compilation is a very large spec
> to add to the build, it's better to make sure cross-compilation is
> reviewed via separate packages than to have it added on to random
> packages willy-nilly.
> 
> 4) Having cross-compiled sub-packages prevents us from separating out
> the cross-compiled packages should that become desirable in the future
> (I sit on Infrastructure and FPC and watch FESCo so I know how difficult
> this is from the infrastructure side and yet how desired it was from the
> other.)  Once again, this is keeping options open for Fedora 27.

This seems very reasonable.  So I'll introduce these as new packages
instead of doing them as subpackages.  (And try to do some more
reviews ...)

Rich.