Re: "slicing" ocaml 3.10.0: comparison with debian friends?
by Richard Jones
On Thu, Jun 14, 2007 at 10:30:53PM +0100, Stefano Zacchiroli wrote:
> Still, native code objects can break link time compatibility with
> compatible .cmis.
I don't understand - why is this?
Rich.
--
Richard Jones
Red Hat
16 years, 10 months
Re: "slicing" ocaml 3.10.0: comparison with debian friends?
by Richard Jones
On Thu, Jun 14, 2007 at 09:05:01PM +0100, Stefano Zacchiroli wrote:
> On Thu, Jun 14, 2007 at 08:29:36PM +0100, Richard Jones wrote:
> > We're actually distributing camlp4 as a separate package. To
> > be honest I hadn't looked at the sizes until now:
>
> Thanks for this list!
>
> Would you mind sending us (maybe as an attachment?) a list of the files
> contained in each package? From this list I can guess the content, but
> just to be sure...
Gemi did this actually. Here is the list of files:
%files camlp4
%defattr(-,root,root,-)
%dir %{_libdir}/ocaml/camlp4
%{_libdir}/ocaml/camlp4/*.cmi
%{_libdir}/ocaml/camlp4/*.cma
%{_libdir}/ocaml/camlp4/*.cmo
%dir %{_libdir}/ocaml/camlp4/Camlp4Filters
%{_libdir}/ocaml/camlp4/Camlp4Filters/*.cmi
%{_libdir}/ocaml/camlp4/Camlp4Filters/*.cmo
%dir %{_libdir}/ocaml/camlp4/Camlp4Parsers
%{_libdir}/ocaml/camlp4/Camlp4Parsers/*.cmo
%{_libdir}/ocaml/camlp4/Camlp4Parsers/*.cmi
%dir %{_libdir}/ocaml/camlp4/Camlp4Printers
%{_libdir}/ocaml/camlp4/Camlp4Printers/*.cmi
%{_libdir}/ocaml/camlp4/Camlp4Printers/*.cmo
%dir %{_libdir}/ocaml/camlp4/Camlp4Top
%{_libdir}/ocaml/camlp4/Camlp4Top/*.cmi
%{_libdir}/ocaml/camlp4/Camlp4Top/*.cmo
%files camlp4-devel
%defattr(-,root,root,-)
%{_bindir}/camlp4*
%{_bindir}/mkcamlp4
%{_libdir}/ocaml/camlp4/*.a
%{_libdir}/ocaml/camlp4/*.cmxa
%{_libdir}/ocaml/camlp4/*.cmx
%{_libdir}/ocaml/camlp4/*.o
%{_libdir}/ocaml/camlp4/Camlp4Filters/*.cmx
%{_libdir}/ocaml/camlp4/Camlp4Filters/*.o
%{_libdir}/ocaml/camlp4/Camlp4Parsers/*.cmx
%{_libdir}/ocaml/camlp4/Camlp4Parsers/*.o
%{_libdir}/ocaml/camlp4/Camlp4Printers/*.cmx
%{_libdir}/ocaml/camlp4/Camlp4Printers/*.o
%{_libdir}/ocaml/camlp4/Camlp4Top/*.cmx
%{_libdir}/ocaml/camlp4/Camlp4Top/*.o
%{_mandir}/man1/*
> > $ rpm -q --requires ocaml-calendar
>
> I'll have a look at your guidelines. In the meantime, can you expand the
> above command for non rpm speakers so that we can parse the output? :)
It just lists the requirements (dependencies) of the ocaml-calendar
package.
For comparison, here are symbols provided by the same:
$ rpm -q --provides ocaml-calendar
ocaml(Calendar) = db8ca9a52d58e744b63d354d36f12620
ocaml(Date) = 57886756cbdb3aa1db37638a7809f610
ocaml(Period) = e220d29e5b87b6ec8b8b474a2ae54685
ocaml(Printer) = 4454f0bfed349268f57ffd82a7d78499
ocaml(Time) = 35fe4ca99bb3640b22bc286fc97adff5
ocaml(Time_Zone) = 23b711a8eb543e69e6f53d67a0eccf57
ocaml-calendar = 1.10-5
The symbols are generated automagically by scanning the OCaml objects
(*.cmi, *.cmo, *.cma) using ocamlobjinfo. The two scripts attached to
this bugzilla do it:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239004
(scroll down to near the bottom).
Rich.
--
Richard Jones
Red Hat
16 years, 10 months
Re: "slicing" ocaml 3.10.0: comparison with debian friends?
by Richard Jones
On Thu, Jun 14, 2007 at 08:02:01PM +0100, Stefano Zacchiroli wrote:
> Hi Richard,
> in Debian we are almost ready to upload an official version of the
> ocaml 3.10.0 packaging [1], I know from the caml mailing list that
> you're working on similar stuff for red hat derivatives.
>
> One of our remaining concern is that the ocaml-nox package is more than
> 100 Mb of installed size. About 70 Mb of that are devoted to camlp4
> executables and libraries, hence we are considering splitting that to a
> separate package.
>
> Have you had similar concerns? If so, which kind of splitting you
> decided to perform? I'll be glad to share opinions with you guys on
> that!
We're actually distributing camlp4 as a separate package. To
be honest I hadn't looked at the sizes until now:
5.7M ocaml-3.10.0-2.x86_64.rpm
22M ocaml-camlp4-3.10.0-2.x86_64.rpm
7.1M ocaml-camlp4-devel-3.10.0-2.x86_64.rpm
3.6M ocaml-debuginfo-3.10.0-2.x86_64.rpm
2.1M ocaml-docs-3.10.0-2.x86_64.rpm
87K ocaml-emacs-3.10.0-2.x86_64.rpm
362K ocaml-findlib-1.1.2pl1-5.x86_64.rpm
130K ocaml-findlib-devel-1.1.2pl1-5.x86_64.rpm
388K ocaml-labltk-3.10.0-2.x86_64.rpm
1.8M ocaml-labltk-devel-3.10.0-2.x86_64.rpm
2.4M ocaml-ocamldoc-3.10.0-2.x86_64.rpm
1.5M ocaml-runtime-3.10.0-2.x86_64.rpm
77K ocaml-source-3.10.0-2.x86_64.rpm
20K ocaml-x11-3.10.0-2.x86_64.rpm
Those sizes are, of course, compressed.
camlp4 is pretty huge, isn't it.
> PS similarly, I know you prepared the red hat derivatives guidelines for
> packaging OCaml stuff and that you started from our policy. Feel free to
> post suggestions for / improvements to our policy to our mailing list.
>
> [1] if you're interested in what we are doing you can find it at:
> http://svn.debian.org/wsvn/pkg-ocaml-maint/trunk/packages/ocaml/branches/...
I'm very much following Debian's policy and packages to see what
you've done and how you've done it.
Fedora policy: http://fedoraproject.org/wiki/PackagingDrafts/OCaml
Despite the name, this has just been approved. You might be
particularly interested in the very strict versioning scheme that
Fedora adopted. For example:
$ rpm -q --requires ocaml-calendar
[...]
ocaml(Array) = aa8e3cd5824f9bb40b93fcd38d0c95b5
ocaml(Buffer) = f6cef633ea14963b84b79c4095c63dc3
ocaml(Format) = 35fe566f7a37d8991a5c822bd1463949
ocaml(Lazy) = 8a4b5e7f0bdc6316df9264fd73cde981
ocaml(List) = da1ce9168f0408ff26158af757456948
ocaml(Pervasives) = 8ba3d1faa24d659525c9025f41fd0c57
ocaml(Str) = 56bb7ee61b2da83d42394686e3558fe4
ocaml(String) = 2c162ab314b2f0a2cfd22d471b2e21ab
ocaml(Unix) = 9a46a8db115947409e54686ada118599
ocaml = 3.10.0-2
And I do have a question actually ...
Why does Debian put version numbers into the paths
(eg. /usr/lib/ocaml/3.09.3/...)? In Fedora we don't do this. The
advantage of putting version numbers in there is it would allow us to
install multiple versions at the same time, but we'd have to go all
the way down to the -release level to make this realistic, _and_ we'd
have to version everything in /usr/bin as well. I'm wondering if
Debian have some deep insight that I'm missing.
Rich.
--
Richard Jones
Red Hat
16 years, 10 months
multilib and concurrent virtual arch-less provides
by Axel Thimm
Hi,
I encountered the following: Dependencies on perl(Foo) virtual
provides can be offered by i386 and x86_64 packages. If these packages
have been tagged as multilibbable then the x86_64 repo has two
different packages offering the same virtual provides.
This means that installing by dependencies, BuildRequires: or
Requires: may be satisfied by the wrong package, or in the best case
by two packages confusing the depsolver.
More precisely I hit this with perl(ExtUtils::MakeMaker) in an emtpy
chroot.
--
Axel.Thimm at ATrpms.net
16 years, 10 months
Missing today's meeting
by Jesse Keating
I have something else taking me away from this time slot today. Apologies.
--
Jesse Keating
Release Engineer: Fedora
16 years, 10 months
OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking)
by Richard W.M. Jones
Toshio Kuratomi wrote:
> On Sun, 2007-04-15 at 23:53 +1200, Nigel Jones wrote:
>> Nigel Jones wrote:
>> > Hi everyone,
>> >
>> > While putting in a couple of packages for Extras Review I've stumbled
>> > into a couple of issues regarding how Ocaml links libraries and how the
>> > Fedora Packaging Guidelines are set.
>> >
>> > My packages in question are:
>> > ocamlSDL (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804)
>> > camlimages (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805)
>> > freetennis (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815)
>> >
>> > Basically, ocamlSDL and camlimages produce two sets of libraries (a set
>> > of dynamic libraries, and another set for development etc), sadly when
>> > other packages like freetennis build, they staticly link to libraries
>> > such as camlimages/ocamlSDL.
>> >
>> > I found it semi-suspect when I built freetennis, and hence why I asked
>> > on bugzilla when I posted the three packages for review, however I did
>> > some more questioning today and after a quick IRC discussion in #ocaml
>> > was told:
>> >
>> > 12/04 13:39 < G> hmmm, .a .cma and .cmxa are all static ocaml libraries
>> > right?
>> > 12/04 13:44 < Smerdyakov> Those are the two library extensions, yes.
>> > 12/04 13:44 < Smerdyakov> Native code OCaml doesn't support dynamic loading.
>> > 12/04 13:44 < Smerdyakov> I expect that bytecode uses the same files for
>> > dynamic loading as static loading.
>> >
>> > Looking at my installed files on my laptop, lablgl, lablgtk and labltk
>> > (as well as the main ocaml package) store .a, .cma and .cmxa files in
>> > /usr/lib/ocaml (and subfolders).
>> >
>> > As I'm only new to Fedora packaging, could someone please advise on
>> > where I should from here on the matter and what the position of FESCO is
>> > on Ocaml static libraries, and where I should go from here.
>> >
>> > Thanks,
>> >
>> > Nigel Jones
>>
>> I'm just wondering if anyone has any thoughts on this issue.
>>
>> I've talked to some more people in #ocaml (Freenode), who suggested that
>> I try a patch by the name of 'scaml' which is a year or two old (and
>> although can be manually applied to the ocaml source, it does not work
>> (problems with assembly which I've not comfortable meddling with).
>>
>> We'd actually need to downgrade to 3.07 which was removed from Fedora in
>> Feb 05 to get the patch working to satisfy the need for dynamic loading
>> which I'm sure would upset a few people.
>>
>> Upstream already have a bug opened stating that they need to fix the
>> issue but they have never updated it, or assigned it to anyone.
>>
>> So my main question is "where to from here?"
>
> I think, if the ocaml compiler doesn't support dynamic libraries, static
> linking would be acceptable. This doesn't mean that we shouldn't press
> upstream to add dynamic linking (and convert all our packages when that
> becomes available) just an acknowledgment that fixing the limitation has
> to be done upstream (it could be done by someone within Fedora but the
> fix needs to go upstream).
>
> This is similar to allowing C libraries in even if they only build
> statically.
>
> If I'm not understanding precisely what the limitation is, feel free to
> clarify.
There are two issues here: (a) Having OCaml binaries link dynamically
instead of statically to OCaml libraries. (b) Writing a dynamic library
in OCaml, and having it used by programs written in other languages,
particularly C.
I suspect it's unlikely that upstream will do (a), ever. There's a
technical issue. OCaml really doesn't have a concept of an ABI. It
does a kind of whole-program optimisation where even changes to the
internal implementation of a library can affect the resulting binary.
Moreover even if you "fixed" that, any change whatsoever to the
library's signature or the version of compiler it was built with (even
bugfix releases which have the same version number) will make the
library incompatible.
You might also find this entertaining:
http://caml.inria.fr/pub/ml-archives/caml-list/2004/05/775714fbf05c17e0cb...
Another issue which Xavier doesn't mention is the ability to fix a
security bug in a shared library, and not require all dependent
applications be recompiled. Well, there aren't many (any?) widely used
OCaml libraries, and there aren't a lot of binaries which would need to
be recompiled either. But it could be a problem for OCaml world
domination plans.
As for (b), the ability to write libraries in a sane language and have
them called through a C API: This almost works. Well, it works well on
i386, but there are some problems on x86-64. I'm looking forward to
having this. It needs some tools to make it work well - it would be
nice to have the C header files and the complex Makefile fragments to
get it to work generated automatically.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
16 years, 10 months
Status of OCaml packaging
by Richard W.M. Jones
Some brief notes on what has happened since last Tuesday w.r.t. OCaml
packaging in Fedora.
Gerard produced the base ocaml package for OCaml 3.10.0 (the latest
upstream version). OCaml 3.10 has some major changes which affect a lot
of upstream packages.
https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01397.html
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239004#c13
http://caml.inria.fr/ocaml/release.en.html
After last Tuesday's meeting I've fixed several things which were problems:
* I've built all but two OCaml packages against OCaml 3.10, including
submitting an upstream patch. The two which don't yet work are
ocaml-pxp and cduce, which both require significant effort upstream.
(http://annexia.org/tmp/ocaml/, http://tinyurl.com/2rl4w6)
* rpmbuild now doesn't call rpm recursively.
* OCaml dependencies now look like ocaml(ModuleName) = Hash
* ocaml-find-requires and ocaml-find-provides scripts are looking more
solid and final, and are working their way into RPM.
(https://www.redhat.com/archives/fedora-devel-list/2007-June/msg01071.html)
* I fixed the way that we split out the -devel subpackage (I think).
(https://www.redhat.com/archives/fedora-packaging/2007-June/msg00064.html)
* All packages now support bytecode architectures.
I've revised the OCaml Packaging Draft guidelines several times. The
latest version is here:
http://fedoraproject.org/wiki/PackagingDrafts/OCaml
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
16 years, 10 months
pre-install and post install instructions in a rpm
by lostson
Hello all
I am trying to package up obconf 2.0 with the new openbox 3.4 and am
having troubles. With obconf upon install and uninstall I need to run
these two commands.
update-mime-database /usr/share/mime
update-desktop-database /usr/share/applications
I was reading some documentation that was talking about possibly using shell
scripts to issue those commands both on install and uninstall. Is this the correct
procedure or is there a more efficient way, thanks.
--
LostSon
http://www.lostsonsvault.org
16 years, 10 months
License text
by Jason L Tibbitts III
The Review Guidelines state:
- MUST: If (and only if) the source package includes the text of the
license(s) in its own file, then that file, containing the text of
the license(s) for the package must be included in %doc.
but this rule is not actually in the packaging guidelines. In fact,
there are various bits which exist in the review document that aren't
mentioned in the guidelines themselves. I guess we should make an
effort to make sure that all of these are dealt with, but one thing at
a time.
So, here's a proposal. I'll draft it in the wiki if folks would
prefer that, but as this isn't actually a change of the guidelines as
a whole (since they include the review guidelines) I think we can just
do a quick vote and if there's no controversy then just make the
change and notify fesco.
Proposal:
Amend the Licensing section of the Guidelines. Immediately
previous to the Shareware subsection, add the following subsection:
----------
=== License Text ===
If (and only if) the source package includes the text of the
license(s) in its own file, then that file, containing the text of the
license(s) for the package must be included as documentation.
----------
- J<
16 years, 10 months
