[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: "slicing" ocaml 3.10.0: comparison with debian friends?



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/ocaml-3.10.0/?rev=0&sc=0

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



Reply to: