Is there a policy which describes precisely what should go into a -devel subpackage?
Here is an example case where I'm unsure:
In OCaml there's a thing called the "toplevel". Think of it as being like the python command line (where you just type "python" on its own, then start typing in Python expressions).
$ ocaml -I +calendar Objective Caml version 3.09.3
# #load "unix.cma";;
# #load "str.cma";;
# #load "calendar.cma";;
# let d = Printer.DatePrinter.from_string "2007-01-01";;
val d : Printer.DatePrinter.t = <abstr> # Printer.DatePrinter.to_string (Date.next d `Week);;
- : string = "2007-01-08"
So my question: If I'm packaging ocaml-calendar (a library) then should the parts which make the above possible go into the main package or ocaml-calendar-devel?
Note that as far as I can see in Python -- and I'm not hugely familiar with that language so forgive me if I've made a mistake -- but it seems they go in the main package.
Another thing is that if I move the parts into the -devel subpackage, then ocaml-calendar will literally be empty!
Rich.
On Fri, 2007-05-25 at 20:01 +0100, Richard W.M. Jones wrote:
Is there a policy which describes precisely what should go into a -devel subpackage?
Here is an example case where I'm unsure:
In OCaml there's a thing called the "toplevel". Think of it as being like the python command line (where you just type "python" on its own, then start typing in Python expressions).
$ ocaml -I +calendar Objective Caml version 3.09.3
# #load "unix.cma";;
# #load "str.cma";;
# #load "calendar.cma";;
# let d = Printer.DatePrinter.from_string "2007-01-01";;
val d : Printer.DatePrinter.t = <abstr> # Printer.DatePrinter.to_string (Date.next d `Week);;
- : string = "2007-01-08"
So my question: If I'm packaging ocaml-calendar (a library) then should the parts which make the above possible go into the main package or ocaml-calendar-devel?
We've already determined that OCaml is ... special.
Here's the rule of thumb I've always used:
In the traditional library/binary model:
The main package is for libraries and components that another binary would need to execute. I can't _run_ foo without libbar.so.6 being present.
The -devel package is for headers and components that are needed to build that binary. I can't _build_ foo without bar.h being present.
So, in the OCaml universe, I'd say those .cma files fall into the main package, as I can't run _foo_ without those .cma files present.
Note that I know absolutely NOTHING about OCaml besides what you've told me.
~spot
Tom "spot" Callaway wrote:
On Fri, 2007-05-25 at 20:01 +0100, Richard W.M. Jones wrote:
So my question: If I'm packaging ocaml-calendar (a library) then should the parts which make the above possible go into the main package or ocaml-calendar-devel?
We've already determined that OCaml is ... special.
Thanks for your prompt reply!
Here's the rule of thumb I've always used:
In the traditional library/binary model:
The main package is for libraries and components that another binary would need to execute. I can't _run_ foo without libbar.so.6 being present.
The -devel package is for headers and components that are needed to build that binary. I can't _build_ foo without bar.h being present.
So, in the OCaml universe, I'd say those .cma files fall into the main package, as I can't run _foo_ without those .cma files present.
In fact because OCaml binaries are statically linked to OCaml libraries foo doesn't require anything to run.
The *.cma file is a bit more like a *.a file, but as ever the parallels aren't precise.
However by the sounds of it, it seems that everything should go in -devel. Is it a problem if the main package is completely empty?
Note that I know absolutely NOTHING about OCaml besides what you've told me.
I've been programming in OCaml nearly exclusively for 4 years, and even _I_ don't know all the ins and outs of the various files used. Mostly this stuff just happens. I had to 'strace' the toplevel running to see which files it needed.
Rich.
On Fri, May 25, 2007 at 08:21:44PM +0100, Richard W.M. Jones wrote:
However by the sounds of it, it seems that everything should go in -devel. Is it a problem if the main package is completely empty?
No, it is not a problem, and it looks like it is the way to go in your case. When there is only a static library in a package the main package is empty.
-- Pat
On Fri, 2007-05-25 at 20:21 +0100, Richard W.M. Jones wrote:
However by the sounds of it, it seems that everything should go in -devel. Is it a problem if the main package is completely empty?
If the main package is empty, don't make one. Just have a -devel section in %files and it won't make a main package, only an SRPM with the main name.
~spot
On Fri, 2007-05-25 at 20:21 +0100, Richard W.M. Jones wrote:
Tom "spot" Callaway wrote:
Here's the rule of thumb I've always used:
In the traditional library/binary model:
The main package is for libraries and components that another binary would need to execute. I can't _run_ foo without libbar.so.6 being present.
The -devel package is for headers and components that are needed to build that binary. I can't _build_ foo without bar.h being present.
So, in the OCaml universe, I'd say those .cma files fall into the main package, as I can't run _foo_ without those .cma files present.
In fact because OCaml binaries are statically linked to OCaml libraries foo doesn't require anything to run.
The *.cma file is a bit more like a *.a file, but as ever the parallels aren't precise.
You have an interesting case here. Like spot, I lean towards the *.cma files being available from the main (non-devel) package as the toplevel and interpreted OCaml scripts won't run without them. They are loadable modules in this sense.
The fact that they are also included statically in compiled OCaml programs seems to be a red herring for this decision but I'm sure their dual nature will raise other interesting issues later.
-Toshio
Toshio Kuratomi wrote:
On Fri, 2007-05-25 at 20:21 +0100, Richard W.M. Jones wrote:
Tom "spot" Callaway wrote:
Here's the rule of thumb I've always used:
In the traditional library/binary model:
The main package is for libraries and components that another binary would need to execute. I can't _run_ foo without libbar.so.6 being present.
The -devel package is for headers and components that are needed to build that binary. I can't _build_ foo without bar.h being present.
So, in the OCaml universe, I'd say those .cma files fall into the main package, as I can't run _foo_ without those .cma files present.
In fact because OCaml binaries are statically linked to OCaml libraries foo doesn't require anything to run.
The *.cma file is a bit more like a *.a file, but as ever the parallels aren't precise.
You have an interesting case here. Like spot, I lean towards the *.cma files being available from the main (non-devel) package as the toplevel and interpreted OCaml scripts won't run without them. They are loadable modules in this sense.
Of course I'd completely forgotten about OCaml scripts ... They're not used very often, but they are an argument for putting the *.cma and *.cmi files into the main package.
Here's an example of an OCaml script, albeit one which in this case doesn't use any external libraries (but in general they can do):
http://en.wikipedia.org/wiki/Objective_CAML#Birthday_paradox
The fact that they are also included statically in compiled OCaml programs seems to be a red herring for this decision but I'm sure their dual nature will raise other interesting issues later.
After playing around with strace, I'm pretty sure that it's safe just to put the *.cma, *.cmi and *.so files (if present) into the main package, to get the toplevel and scripts working.
That is what I did in these spec files:
http://annexia.org/tmp/ocaml-extlib.spec [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240655] http://annexia.org/tmp/ocaml-calendar.spec [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240571] http://annexia.org/tmp/ocaml-pcre.spec [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240652]
Rich.
packaging@lists.fedoraproject.org