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

Re: future: automatic and sound OCaml dependencies



On Wed, Feb 18, 2009 at 10:05:46AM +0100, Stefano Zacchiroli wrote:
> The topic is a long standing one, how to have automatically computed
> and sound dependencies among OCaml packages in Debian. On the topic,
> I've finally found the time (last month) to write an essay summarizing
> the problem, the historical solutions, and the (supposedly) "good"
> solution discussed back in DebConf7 together with some of us and the
> release team. The essay has been made available on the web some days
> ago and linked from our wiki page, here is a direct link to the PDF:
> 
>   http://upsilon.cc/~zack/stuff/ocaml-debian-deps.pdf
>   (it is linked from http://wiki.debian.org/Teams/OCamlTaskForce, the
>    PDF contain links to the Git repo of the document) 

Hmmm ..  I think you misunderstand what Fedora is doing.  Our deps
simply take the current MD5 sums as used by the OCaml compiler, and we
map those directly into package dependencies.

For example:

  $ rpm -qR ocaml-extlib
  rpmlib(PayloadFilesHavePrefix) <= 4.0-1
  rpmlib(CompressedFileNames) <= 3.0.4-1
  rpmlib(VersionedDependencies) <= 3.0.3-1
  ocaml(Array) = aa8e3cd5824f9bb40b93fcd38d0c95b5
  ocaml(Buffer) = f6cef633ea14963b84b79c4095c63dc3
  ocaml(CamlinternalOO) = 6d0d5b328d6db88f403ca4393b4abd38
  ocaml(Char) = e98bc9c9e918a84b3c1a5a122d42fac1
  ocaml(Filename) = 633a1e7f590ff5e95124293dbef3b476
  ocaml(Hashtbl) = 083f2c94b44ff4e0b3220aaea6a783b4
  ocaml(Int32) = 711321870c949bd3bbdd092d9bae92e4
  ocaml(Int64) = f8f7e2e4c0667ead94596040b12e732d
  ocaml(List) = da1ce9168f0408ff26158af757456948
  ocaml(Obj) = 5cfae708052c692ea39d23ed930fd64d
  ocaml(Pervasives) = 8ba3d1faa24d659525c9025f41fd0c57
  ocaml(Printf) = 5dbbf45a03b54e6dbfcf39178d0d6341
  ocaml(String) = 2c162ab314b2f0a2cfd22d471b2e21ab
  ocaml(Sys) = 0da495f5a80f31899139359805318f28
  ocaml(runtime) = 3.10.2

These dependencies are generated and depsolved completely
automatically, without any human intervention at all, so,

  "it provides virtual package names which are not only
  entirely meaningless for humans, but also hard to grasp
  for people who sooner or later will have to deal with them".

isn't true.  (I assume dh_ocaml can generate dependencies
automatically by examining the *.cmo & *.cma files contained in the
final binary package?)

Rich.

-- 
Richard Jones
Red Hat


Reply to: