MinGW subpackages of OCaml packages

Richard W.M. Jones rjones at redhat.com
Fri Dec 5 23:12:25 UTC 2008


So as I mentioned before we have an OCaml Windows cross-compiler as
part of the Fedora MinGW project:

http://hg.et.redhat.com/misc/fedora-mingw--devel/
  (click 'manifest' then 'ocaml' or the 'ocaml-*' subdirectories)
  mingw32-ocaml               - the cross-compiler (native Fedora prog)
  mingw32-ocaml-calendar      - cross-compiled OCaml Calendar library
  mingw32-ocaml-csv           - cross-compiled OCaml CSV library
  mingw32-ocaml-curses        - cross-compiled OCaml curses bindings
  mingw32-ocaml-extlib        - cross-compiled OCaml extlib (library)
  mingw32-ocaml-findlib       - (this just has a single config file)
  mingw32-ocaml-lablgl        - cross-compiled OCaml OpenGL bindings
  mingw32-ocaml-lablgtk       - cross-compiled OCaml Gtk bindings
  mingw32-ocaml-libvirt       - cross-compiled OCaml libvirt bindings
  mingw32-ocaml-xml-light     - cross-compiled OCaml XML library

When we were doing the original packaging, we explored the option of
building the MinGW packages as subpackages of the native Fedora
packages, eg: the gnutls specfile would contain the '-n mingw32-gnutls'
subpackage.  This would have made it simpler to keep the packages in
synch with native Fedora, but we felt that native packagers wouldn't
be so happy about this.  They wouldn't be expert in MinGW packaging,
and would drop the MinGW subpackage at the first sign of trouble.

However, since I'm in the unique position of maintaining most of the
corresponding ocaml-* (native) and mingw32-ocaml-* (cross-compiled)
packages, I would like to ask whether I can create the packages above
and others in future as subpackages of the already approved ocaml-*
native packages.

I'm not looking for any exception to the relevant packaging
guidelines, which I would try to follow (excepting any mistakes).

If you want to see what some RPMs look like, see:
  http://www.annexia.org/tmp/mingw/fedora-10/x86_64/RPMS/

Thoughts?  I set follow-ups to the fedora-packaging list.

Rich.




More information about the fedora-devel-list mailing list