Hi all,
I got looking into this because of these review requests: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815
And I've come to the conclusion that we need some kinda ocaml packaging guidelines.
Interesting with regards to this are: http://docs.pld-linux.org/ocaml.html http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.txt
Which are PLD resp debian ocaml guidelines. And they seem to agree on most things.
Notice that I've exactly 0 experience in packaging or writing caml software, this is all based on common sense and my observations with the 3 packages above.
OCaml Guidelines ================
Naming ------ OCaml modules / libs should be named ocaml-foo. (This does not apply to applications written in caml). Rationale: this is how they are named in other distros (Debian, PLD) and this is consistent with perl / php / python.
-devel sub-packages ------------------- OCaml software can either be byte compiled, in which case it will need the ocaml runtime and besides the runtime only the files installed by libs / modules under /usr/lib/ocaml/stublibs (the ocaml byte code from libs gets staticly linked into the bytecode-"executable"_.
Or they can be compiled to native code in which case all caml specific libs / bindings get staticly linked into the executable (wrapped libraries themself will still be dynamicly linked, but the wrapper code is linked staticly into the executable, this can not be changed).
Thus for ocaml modules / lib(wrapper)s, in the case of byte compiled ocaml programs only the files under /usr/lib/ocaml/stublibs from the module/lib are needed, and to run a compiled program nothing from the module/lib is needed.
So only the files under /usr/lib/ocaml/stublibs should be in the mainpackage, and if there are no such files (in case of a pure caml module / lib) then the mainpackage should have an empty %files. All other files should go in a -devel package as they are only needed to compile and no to run ocaml programs.
Unnecessary files ----------------- This is taken from: http://docs.pld-linux.org/ocaml.html Following files should NOT be distributed:
- *.cmo object files. There is however one exception -- if file is needed for link (like gtkInit.cmo in lablgtk or std_exit.cmo in OCaml itself), then it should be of course included.
- *.o for corresponding *.cmx. They are included in *.a anyway. Exception -- as above.
- *.ml sources.
- *.mli interface sources. However, if package lacks any documentation (which is unfortunately often the case), you can include *.mli, but it should be gziped and placed in package as %doc.
Regards,
Hans
On Wed, 2007-05-02 at 21:03 +0200, Hans de Goede wrote:
I got looking into this because of these review requests: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815
And I've come to the conclusion that we need some kinda ocaml packaging guidelines.
Interesting with regards to this are: http://docs.pld-linux.org/ocaml.html http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.txt
Maybe you could start an add something to the fedoraproject wiki, for example a Ocaml SIG. There has also been some interest in this by Richard Jones rjones@redhat.com.
Gérard Milmeister wrote:
On Wed, 2007-05-02 at 21:03 +0200, Hans de Goede wrote:
I got looking into this because of these review requests: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815
And I've come to the conclusion that we need some kinda ocaml packaging guidelines.
Interesting with regards to this are: http://docs.pld-linux.org/ocaml.html http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.txt
Maybe you could start an add something to the fedoraproject wiki, for example a Ocaml SIG. There has also been some interest in this by Richard Jones rjones@redhat.com.
Thanks for alerting me to this Gerard.
I did post to caml-list a while back about the lack of a comprehensive range of OCaml packages in Fedora (versus the case with Debian, for example, where the supported packages are both comprehensive and of very high quality).
I didn't get much response, but I'd really like to help out.
At my previous company I wrote and maintained a great deal of OCaml software: http://merjis.com/developers
Rich.
Gérard Milmeister wrote:
On Wed, 2007-05-02 at 21:03 +0200, Hans de Goede wrote:
I got looking into this because of these review requests: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815
And I've come to the conclusion that we need some kinda ocaml packaging guidelines.
Interesting with regards to this are: http://docs.pld-linux.org/ocaml.html http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.txt
Maybe you could start an add something to the fedoraproject wiki, for example a Ocaml SIG. There has also been some interest in this by Richard Jones rjones@redhat.com.
Yes an ocaml sig probably is a good idea. But as said I'm only the reviewer here, so to those interested, go ahead create a sig. Maybe Nigel Jones will want to join you too, as he is the submitter of the package review requests linked to above.
Either way we need to put down some guidelines, since the current ocaml packages aren't packaged properly (when judging them by the debian / PLD guidelines).
Regards,
Hans
On Thu, 2007-05-03 at 20:17 +0200, Hans de Goede wrote:
Gérard Milmeister wrote:
On Wed, 2007-05-02 at 21:03 +0200, Hans de Goede wrote:
I got looking into this because of these review requests: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815
And I've come to the conclusion that we need some kinda ocaml packaging guidelines.
Interesting with regards to this are: http://docs.pld-linux.org/ocaml.html http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.txt
Maybe you could start an add something to the fedoraproject wiki, for example a Ocaml SIG. There has also been some interest in this by Richard Jones rjones@redhat.com.
Yes an ocaml sig probably is a good idea. But as said I'm only the reviewer here, so to those interested, go ahead create a sig. Maybe Nigel Jones will want to join you too, as he is the submitter of the package review requests linked to above.
Either way we need to put down some guidelines, since the current ocaml packages aren't packaged properly (when judging them by the debian / PLD guidelines).
I can help get the guidelines approved but I'm not an OCaml packager so most of the work will be up to you guys. Discuss the guidelines, either put something under /wiki/PackagingDrafts/ or ping me with a copy that you want to propose and I'll do it. Then it would be tremendously helpful if one of you could make it to a Packaging Meeting where the Guideline gets discussed by the Packaging Committee. That way you can field questions immediately instead of me being a go-between.
-Toshio
Toshio Kuratomi wrote:
On Thu, 2007-05-03 at 20:17 +0200, Hans de Goede wrote:
Gérard Milmeister wrote:
On Wed, 2007-05-02 at 21:03 +0200, Hans de Goede wrote:
I got looking into this because of these review requests: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815
And I've come to the conclusion that we need some kinda ocaml packaging guidelines.
Interesting with regards to this are: http://docs.pld-linux.org/ocaml.html http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.txt
Maybe you could start an add something to the fedoraproject wiki, for example a Ocaml SIG. There has also been some interest in this by Richard Jones rjones@redhat.com.
Yes an ocaml sig probably is a good idea. But as said I'm only the reviewer here, so to those interested, go ahead create a sig. Maybe Nigel Jones will want to join you too, as he is the submitter of the package review requests linked to above.
Either way we need to put down some guidelines, since the current ocaml packages aren't packaged properly (when judging them by the debian / PLD guidelines).
I can help get the guidelines approved but I'm not an OCaml packager so most of the work will be up to you guys. Discuss the guidelines, either put something under /wiki/PackagingDrafts/ or ping me with a copy that you want to propose and I'll do it. Then it would be tremendously helpful if one of you could make it to a Packaging Meeting where the Guideline gets discussed by the Packaging Committee. That way you can field questions immediately instead of me being a go-between.
Okay,
The proposal I mailed to the list yesterday is now available here: http://fedoraproject.org/wiki/PackagingDrafts/OCaml
If you can let me know where and when the FPC meeting happens, then I can see if I can attend (times in CET please, as a european I'm not used to doing timezone calculations)
Regards,
Hans
"HdG" == Hans de Goede j.w.r.degoede@hhs.nl writes:
HdG> If you can let me know where and when the FPC meeting happens, HdG> then I can see if I can attend (times in CET please, as a HdG> european I'm not used to doing timezone calculations)
#fedora-meeting, 1700UTC. I believe that's 1900CET, according to timezoneconverter.com.
- J<
On Thu, 2007-05-03 at 21:23 +0200, Hans de Goede wrote:
Okay,
The proposal I mailed to the list yesterday is now available here: http://fedoraproject.org/wiki/PackagingDrafts/OCaml
Thanks Hans! I have a question about bytecode/native code. Should the guidelines specify that module packages build both bytecode and native code? As a precedent, a java library will install a native code version to %{_libdir}/libfoo-1.0.so and byte code to /usr/share/java/foo-1.0.jar.
I also wonder if we want to specify that ocaml programs should be compiled to native code.
If you can let me know where and when the FPC meeting happens, then I can see if I can attend (times in CET please, as a european I'm not used to doing timezone calculations)
I believe that tibbs answered this.
Thanks, -Toshio
Toshio Kuratomi wrote:
On Thu, 2007-05-03 at 21:23 +0200, Hans de Goede wrote:
Okay,
The proposal I mailed to the list yesterday is now available here: http://fedoraproject.org/wiki/PackagingDrafts/OCaml
Thanks Hans!
Please keep in mind I'm not an ocaml expert, I just did some reading on it as I needed to know something about it todo reviews.
I have a question about bytecode/native code. Should the guidelines specify that module packages build both bytecode and native code? As a precedent, a java library will install a native code version to %{_libdir}/libfoo-1.0.so and byte code to /usr/share/java/foo-1.0.jar.
Thats not how ocaml handles things. Ocaml code gets compiled to bytecode objects, native<->ocaml glue code gets compiled to native objects.
Then when compiling an application / program, you can compile it in 2 ways: 1) to a bytecode program which will require the ocaml runtime and the .so versions of any native code from used modules/libs. All bytecode objects from used modules will get staticly liked in.
This reminds me, since ocaml will dlopen the .so files with native code of used modules, an application compiled this way should have Requires: for all used modules of which native parts are used.
2) To native code, in this case the bytecode parts of used modules get converted to native code and any native objects which are part of modules get staticly linked in, resulting in a native binary which is independent of any ocaml modules (but which will still depend upon any be dynamicly linked against any normal native libraries used by modules, like libjpeg)
I also wonder if we want to specify that ocaml programs should be compiled to native code.
According to Debian's guidelines this has both advantages and disadvantages, so its probably best to use upstream's default behaviour.
Also worth noticing is that native compilation is not available on all platforms. Luckily it is available for all platforms which are part of Fedora.
Regards,
Hans
p.s.
What do you think about the Naming part of the proposal? I'm currently doing an ocaml related review which mainly needs a "decision" on the naming part of the proposal. I think this is not very controversial, so if atleast an agreement could be reached on this, then said review can move forward.
Toshio Kuratomi wrote:
On Thu, 2007-05-03 at 21:23 +0200, Hans de Goede wrote:
Okay,
The proposal I mailed to the list yesterday is now available here: http://fedoraproject.org/wiki/PackagingDrafts/OCaml
Thanks Hans!
Please keep in mind I'm not an ocaml expert, I just did some reading on it as I needed to know something about it todo reviews.
I have a question about bytecode/native code. Should the guidelines specify that module packages build both bytecode and native code? As a precedent, a java library will install a native code version to %{_libdir}/libfoo-1.0.so and byte code to /usr/share/java/foo-1.0.jar.
Thats not how ocaml handles things. Ocaml code gets compiled to bytecode objects, native<->ocaml glue code gets compiled to native objects.
Then when compiling an application / program, you can compile it in 2 ways:
- to a bytecode program which will require the ocaml runtime and the .so versions of any native code from used modules/libs. All bytecode
objects from used modules will get staticly liked in.
This reminds me, since ocaml will dlopen the .so files with native
code of used modules, an application compiled this way should have Requires: for all used modules of which native parts are used.
- To native code, in this case the bytecode parts of used modules get converted to native code and any native objects which are part of
modules get staticly linked in, resulting in a native binary which is independent of any ocaml modules (but which will still depend upon any be dynamicly linked against any normal native libraries used by modules, like libjpeg)
I also wonder if we want to specify that ocaml programs should be compiled to native code.
According to Debian's guidelines this has both advantages and disadvantages, so its probably best to use upstream's default behaviour.
Also worth noticing is that native compilation is not available on all platforms. Luckily it is available for all platforms which are part of Fedora.
Regards,
Hans
p.s.
What do you think about the Naming part of the proposal? I'm currently doing an ocaml related review which mainly needs a "decision" on the naming part of the proposal. I think this is not very controversial, so if atleast an agreement could be reached on this, then said review can move forward.
I'm actually happy with it, I'm going to change the name in the review shortly.
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Toshio Kuratomi wrote:
I also wonder if we want to specify that ocaml programs should be compiled to native code.
David Allsopp reminded me (in a private email) that byte code and native code programs also differ in functionality. For example, Dynlink is not available to native code - which is the reason why mod_caml is always compiled to bytecode, even though in theory it could be compiled to native code on platforms which support that.
Rich.
Hans de Goede wrote:
The proposal I mailed to the list yesterday is now available here: http://fedoraproject.org/wiki/PackagingDrafts/OCaml
What's the thinking behind removing *.mli by default? Even in packages which are well documented, the *.mli files are the definitive reference for programmers. I think they should always be in the -devel subpackage.
Debian even include *.ml files in certain situations:
$ dpkg -S /usr/lib/ocaml/3.08.3/list.ml ocaml-nox: /usr/lib/ocaml/3.08.3/list.ml
Along the same lines I notice that there is no version information in the path. Early on Debian used the major.minor format (eg. /usr/lib/ocaml/3.06/) but they found out the hard way that the *.cmo & *.cmx format can change incompatibly on every release (even bugfixes) so they now put the full version number in the path. See:
http://lists.debian.org/debian-ocaml-maint/2005/01/msg00067.html http://lists.debian.org/debian-ocaml-maint/2005/01/msg00050.html http://lists.debian.org/debian-ocaml-maint/2005/01/msg00056.html
Rich.
Sorry to come into the discussion a bit later than expected. Richard W.M. Jones wrote:
Hans de Goede wrote:
The proposal I mailed to the list yesterday is now available here: http://fedoraproject.org/wiki/PackagingDrafts/OCaml
What's the thinking behind removing *.mli by default? Even in packages which are well documented, the *.mli files are the definitive reference for programmers. I think they should always be in the -devel subpackage.
I replaced it in ocaml-SDL and ocaml-camlimages with ocamldoc generated html references, which seems to be pretty much the same as the individual mli files.
Debian even include *.ml files in certain situations:
$ dpkg -S /usr/lib/ocaml/3.08.3/list.ml ocaml-nox: /usr/lib/ocaml/3.08.3/list.ml
It seems to be a case of when they are provided in make install, include them.
Along the same lines I notice that there is no version information in the path. Early on Debian used the major.minor format (eg. /usr/lib/ocaml/3.06/) but they found out the hard way that the *.cmo & *.cmx format can change incompatibly on every release (even bugfixes) so they now put the full version number in the path. See:
Good point, this needs to be looked at by the ocaml maintainer (CC'd)
http://lists.debian.org/debian-ocaml-maint/2005/01/msg00067.html http://lists.debian.org/debian-ocaml-maint/2005/01/msg00050.html http://lists.debian.org/debian-ocaml-maint/2005/01/msg00056.html
Rich.
N.J.
Nigel Jones wrote:
Sorry to come into the discussion a bit later than expected. Richard W.M. Jones wrote:
Hans de Goede wrote:
The proposal I mailed to the list yesterday is now available here: http://fedoraproject.org/wiki/PackagingDrafts/OCaml
What's the thinking behind removing *.mli by default? Even in packages which are well documented, the *.mli files are the definitive reference for programmers. I think they should always be in the -devel subpackage.
I replaced it in ocaml-SDL and ocaml-camlimages with ocamldoc generated html references, which seems to be pretty much the same as the individual mli files.
But I wanna use 'less'!
Seriously, I don't want to fire up a browser just to check an interface. Even the text mode browsers have serious UI problems compared to 'less /usr/lib/ocaml/3.08.3/list.mli'.
Is there any reason why *.mli files can't be included in a -devel package? I'm not talking about the main library package where it would add bloat, but in a package which would only need to be installed by developers.
Rich.
Richard W.M. Jones wrote:
Nigel Jones wrote:
Sorry to come into the discussion a bit later than expected. Richard W.M. Jones wrote:
Hans de Goede wrote:
The proposal I mailed to the list yesterday is now available here: http://fedoraproject.org/wiki/PackagingDrafts/OCaml
What's the thinking behind removing *.mli by default? Even in packages which are well documented, the *.mli files are the definitive reference for programmers. I think they should always be in the -devel subpackage.
I replaced it in ocaml-SDL and ocaml-camlimages with ocamldoc generated html references, which seems to be pretty much the same as the individual mli files.
But I wanna use 'less'!
Seriously, I don't want to fire up a browser just to check an interface. Even the text mode browsers have serious UI problems compared to 'less /usr/lib/ocaml/3.08.3/list.mli'.
Is there any reason why *.mli files can't be included in a -devel package? I'm not talking about the main library package where it would add bloat, but in a package which would only need to be installed by developers.
Other then size, no. So if there is a use for them, and appearantly there is, I guess the not shipping of them should be removed from the guidelines (thats why they are a draft :)
Regards,
Hans
On Fri, 2007-05-04 at 10:58 +0100, Richard W.M. Jones wrote:
Nigel Jones wrote:
Sorry to come into the discussion a bit later than expected. Richard W.M. Jones wrote:
Hans de Goede wrote:
The proposal I mailed to the list yesterday is now available here: http://fedoraproject.org/wiki/PackagingDrafts/OCaml
What's the thinking behind removing *.mli by default? Even in packages which are well documented, the *.mli files are the definitive reference for programmers. I think they should always be in the -devel subpackage.
I replaced it in ocaml-SDL and ocaml-camlimages with ocamldoc generated html references, which seems to be pretty much the same as the individual mli files.
But I wanna use 'less'!
Seriously, I don't want to fire up a browser just to check an interface. Even the text mode browsers have serious UI problems compared to 'less /usr/lib/ocaml/3.08.3/list.mli'.
Is there any reason why *.mli files can't be included in a -devel package? I'm not talking about the main library package where it would add bloat, but in a package which would only need to be installed by developers.
+1
Richard W.M. Jones wrote:
Nigel Jones wrote:
Sorry to come into the discussion a bit later than expected. Richard W.M. Jones wrote:
Hans de Goede wrote:
The proposal I mailed to the list yesterday is now available here: http://fedoraproject.org/wiki/PackagingDrafts/OCaml
What's the thinking behind removing *.mli by default? Even in packages which are well documented, the *.mli files are the definitive reference for programmers. I think they should always be in the -devel subpackage.
I replaced it in ocaml-SDL and ocaml-camlimages with ocamldoc generated html references, which seems to be pretty much the same as the individual mli files.
But I wanna use 'less'!
Seriously, I don't want to fire up a browser just to check an interface. Even the text mode browsers have serious UI problems compared to 'less /usr/lib/ocaml/3.08.3/list.mli'.
Is there any reason why *.mli files can't be included in a -devel package? I'm not talking about the main library package where it would add bloat, but in a package which would only need to be installed by developers.
Technically, if we are going to package developer documentation, they should be in a noarch -doc package (i.e. ocaml-camlimages-doc).
What I'd suggest is: Packager splits out .mli files from build, compresses and gunzips them, and creates a spec file, something to the tune of:
---- [njones@ip-96 SPECS]$ cat ocaml-camlimages-doc.spec Name: ocaml-camlimages-doc Version: 2.2.0 Release: 1%{?dist} Summary: Developer Documentation for ocaml-camlimages
Group: Documentation License: LGPL URL: - Source0: ocaml-camlimages-doc-2.2.0.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) BuildArch: noarch BuildRequires: texinfo ocaml ocaml-ocamldoc ocaml-camlimages-devel
%description Dev Docu....
%prep %setup -q
%build ocamldoc.opt -texi -I /usr/lib/ocaml/lablgtk2/ \ -I /usr/lib/ocaml/camlimages/ -t "camlimages" \ -info-section "Ocaml Libraries" -intf *.* makeinfo ocamldoc.texi gzip camlimages.info
%install rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT/usr/lib/ocaml/camlimages mkdir -p $RPM_BUILD_ROOT/usr/share/info cp -p *.mli $RPM_BUILD_ROOT/usr/lib/ocaml/camlimages/ cp -p *.info.gz $RPM_BUILD_ROOT/usr/share/info
%clean rm -rf $RPM_BUILD_ROOT
%post /sbin/install-info \ --entry "* camlimages: (camlimages). OCaml image processing library" \ --section "Ocaml Libraries" \ %{_infodir}/camlimages.info \ %{_infodir}/dir 2>/dev/null || :
%preun if [ $1 -eq 0 ]; then /sbin/install-info --delete %{_infodir}/camlimages.info %{_infodir}/dir 2>/dev/null || : fi
%files %defattr(-,root,root,-) /usr/lib/ocaml/camlimages/*.mli %{_infodir}/*
%changelog ----
This satisfies the answer of "I want my mli files" and "I want something a bit more meaty".
I agree that html documentation wasn't the best choice, but this could work.
N.J.
On Fri, 04 May 2007 23:07:12 +1200 Nigel Jones dev@nigelj.com wrote:
Richard W.M. Jones wrote:
Nigel Jones wrote:
Sorry to come into the discussion a bit later than
expected.
Richard W.M. Jones wrote:
Hans de Goede wrote:
The proposal I mailed to the list yesterday is now
available here:
What's the thinking behind removing *.mli by default?
Even in packages
which are well documented, the *.mli files are the
definitive reference
for programmers. I think they should always be in
the -devel
subpackage.
I replaced it in ocaml-SDL and ocaml-camlimages with
ocamldoc generated
html references, which seems to be pretty much the
same as the
individual mli files.
But I wanna use 'less'!
Seriously, I don't want to fire up a browser just to
check an interface.
Even the text mode browsers have serious UI problems
compared to
'less /usr/lib/ocaml/3.08.3/list.mli'.
Is there any reason why *.mli files can't be included
in a -devel
package? I'm not talking about the main library
package where it would
add bloat, but in a package which would only need to be
installed by
developers.
Technically, if we are going to package developer documentation, they should be in a noarch -doc package (i.e. ocaml-camlimages-doc).
What I'd suggest is: Packager splits out .mli files from build, compresses and gunzips them, and creates a spec file, something to the tune of:
No please, I don't know what the size of the htmldocs is, but assuming there small lets just have the htmldocs and the *.mli files in the main package, maybe in a seperate subpackage.
If the size of the htmldocs is so large that the additional mirror churn for updates to the main package are woth seperating, then only the htmldocs should be packaged seperately.
Using parts of the build output from one package and manually copying them that as source for another is just plain wrong. And since we are not talking 100Mb data files here, lets not do this!
Regards,
Hans
Richard W.M. Jones wrote:
http://lists.debian.org/debian-ocaml-maint/2005/01/msg00067.html http://lists.debian.org/debian-ocaml-maint/2005/01/msg00050.html http://lists.debian.org/debian-ocaml-maint/2005/01/msg00056.html
Reading further into that thread reminds me of how Fedora OCaml _shouldn't_ emulate Debian, w.r.t. the build process:
http://lists.debian.org/debian-ocaml-maint/2005/01/msg00061.html
(I know zero about the Fedora build process)
Rich.
Richard W.M. Jones wrote:
Hans de Goede wrote:
The proposal I mailed to the list yesterday is now available here: http://fedoraproject.org/wiki/PackagingDrafts/OCaml
What's the thinking behind removing *.mli by default? Even in packages which are well documented, the *.mli files are the definitive reference for programmers. I think they should always be in the -devel subpackage.
This is taken from then PLD guidelines, I'm open to changing this. They advice to put the mli files (gzipped) in %doc when necessary, but to not ship them when there are other docs.
Along the same lines I notice that there is no version information in the path. Early on Debian used the major.minor format (eg. /usr/lib/ocaml/3.06/) but they found out the hard way that the *.cmo & *.cmx format can change incompatibly on every release (even bugfixes) so they now put the full version number in the path. See:
http://lists.debian.org/debian-ocaml-maint/2005/01/msg00067.html http://lists.debian.org/debian-ocaml-maint/2005/01/msg00050.html http://lists.debian.org/debian-ocaml-maint/2005/01/msg00056.html
Yes, I think that adding version info to the ocaml lib path would be a good idea, however the already existing packages don't do this, hence I didn't put it in my proposal. This would be something todo at the beginning of the F8 cycle, if we agree that we want to change this.
Regards,
Hans
On Fri, 2007-05-04 at 12:03 +0200, Hans de Goede wrote:
Richard W.M. Jones wrote:
Hans de Goede wrote:
The proposal I mailed to the list yesterday is now available here: http://fedoraproject.org/wiki/PackagingDrafts/OCaml
What's the thinking behind removing *.mli by default? Even in packages which are well documented, the *.mli files are the definitive reference for programmers. I think they should always be in the -devel subpackage.
This is taken from then PLD guidelines, I'm open to changing this. They advice to put the mli files (gzipped) in %doc when necessary, but to not ship them when there are other docs.
Along the same lines I notice that there is no version information in the path. Early on Debian used the major.minor format (eg. /usr/lib/ocaml/3.06/) but they found out the hard way that the *.cmo & *.cmx format can change incompatibly on every release (even bugfixes) so they now put the full version number in the path. See:
http://lists.debian.org/debian-ocaml-maint/2005/01/msg00067.html http://lists.debian.org/debian-ocaml-maint/2005/01/msg00050.html http://lists.debian.org/debian-ocaml-maint/2005/01/msg00056.html
Yes, I think that adding version info to the ocaml lib path would be a good idea, however the already existing packages don't do this, hence I didn't put it in my proposal. This would be something todo at the beginning of the F8 cycle, if we agree that we want to change this.
Maybe we should open a bug report against ocaml, so we can take the discussion off this list. Some changes have to be done to that package anyways.
On Fri, 04 May 2007 13:24:18 +0200 Gérard Milmeister gemi@bluewin.ch wrote:
On Fri, 2007-05-04 at 12:03 +0200, Hans de Goede wrote:
Richard W.M. Jones wrote:
Hans de Goede wrote:
The proposal I mailed to the list yesterday is now
available here:
What's the thinking behind removing *.mli by default?
Even in packages
which are well documented, the *.mli files are the
definitive reference
for programmers. I think they should always be in
the -devel subpackage.
This is taken from then PLD guidelines, I'm open to
changing this. They advice
to put the mli files (gzipped) in %doc when necessary,
but to not ship them
when there are other docs.
Along the same lines I notice that there is no
version information in
the path. Early on Debian used the major.minor
format (eg.
/usr/lib/ocaml/3.06/) but they found out the hard way
that the *.cmo &
*.cmx format can change incompatibly on every release
(even bugfixes) so
they now put the full version number in the path.
See:
http://lists.debian.org/debian-ocaml-maint/2005/01/msg00067.html
http://lists.debian.org/debian-ocaml-maint/2005/01/msg00050.html
http://lists.debian.org/debian-ocaml-maint/2005/01/msg00056.html
Yes, I think that adding version info to the ocaml lib
path would be a good
idea, however the already existing packages don't do
this, hence I didn't put
it in my proposal. This would be something todo at the
beginning of the F8
cycle, if we agree that we want to change this.
Maybe we should open a bug report against ocaml, so we can take the discussion off this list. Some changes have to be done to that package anyways.
Thats sounds like a good plan, when you do, please send a link as reply in this thread, so that interested people can add themselves to the CC,
Regards,
Hans
Gérard Milmeister wrote:
On Wed, 2007-05-02 at 21:03 +0200, Hans de Goede wrote:
I got looking into this because of these review requests: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815
And I've come to the conclusion that we need some kinda ocaml packaging guidelines.
Interesting with regards to this are: http://docs.pld-linux.org/ocaml.html http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.txt
Maybe you could start an add something to the fedoraproject wiki, for example a Ocaml SIG. There has also been some interest in this by Richard Jones rjones@redhat.com.
I think an SIG would be useful, not only to develop standards, but also to improve the general quality of ocaml based packages in Fedora.
It'd also be useful to coordinate changes like emulating w.r.t policy if needed (as Richard points out), and deciding on items like how documentation should be presented.
N.J.
I opened a bugzilla entry at: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239004 So we can move the discussion there.
I created a SIG.
I've no idea if I did it right.
Nevertheless: http://fedoraproject.org/wiki/SIGs/OCaml
Rich.
Probably missing something here, but I'm reading http://fedoraproject.org/wiki/Packaging/Guidelines and I'm all set to have a go creating RPMs for some OCaml packages. However where do I post the spec files for discussion/inclusion?
Rich.
Richard W.M. Jones wrote:
Probably missing something here, but I'm reading http://fedoraproject.org/wiki/Packaging/Guidelines and I'm all set to have a go creating RPMs for some OCaml packages. However where do I post the spec files for discussion/inclusion?
Rich.
See http://fedoraproject.org/wiki/Packaging/Committee#head-bc786fd8400956418c30a...
Rahul
Rahul Sundaram wrote:
Richard W.M. Jones wrote:
Probably missing something here, but I'm reading http://fedoraproject.org/wiki/Packaging/Guidelines and I'm all set to have a go creating RPMs for some OCaml packages. However where do I post the spec files for discussion/inclusion?
Rich.
See http://fedoraproject.org/wiki/Packaging/Committee#head-bc786fd8400956418c30a...
Oops. never mind. Read that wrong.
Rahul
Richard W.M. Jones wrote:
Probably missing something here, but I'm reading http://fedoraproject.org/wiki/Packaging/Guidelines and I'm all set to have a go creating RPMs for some OCaml packages. However where do I post the spec files for discussion/inclusion?
Rich.
See: http://fedoraproject.org/wiki/PackageMaintainers/NewPackageProcess
And more specificly fill in this form / bugzilla template: https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora%20Extras&a...
Regards,
Hans
Hans de Goede wrote:
Richard W.M. Jones wrote:
Probably missing something here, but I'm reading http://fedoraproject.org/wiki/Packaging/Guidelines and I'm all set to have a go creating RPMs for some OCaml packages. However where do I post the spec files for discussion/inclusion?
Rich.
See: http://fedoraproject.org/wiki/PackageMaintainers/NewPackageProcess
And more specificly fill in this form / bugzilla template: https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora%20Extras&a...
Very fast and encouraging responses. Thank you both.
Rich.
I had a go at producing a package for findlib:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240557
Rich.