On Tue, Feb 24, 2009 at 10:08:11PM +0000, Richard Jones wrote:
> 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.
I think I got it correctly, even though I might have expressed it
wrongly or inappropriately, let's see.
> For example:
Yep, that was clear to me.
> 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".
Let me explain what I meant with this paragraph. Paragraph that,
actually, descends from an objection to the "Fedora approach" we got
from our release managers. The objection was that during migration to
testing someone (the release managers) will sooner or later need to
face a line like:
> ocaml(List) = da1ce9168f0408ff26158af757456948
because that line might be the reason why a package is uninstallable
in testing (even temporarily). That someone will then have to
understand which packages fix it, and doing so with a 16 characters
long hash is not necessarily handy. That was the point of "meaningless
for humans", where maybe "humans" can be replaced for "non-OCaml
programmers" (even though even for them md5sum are not "handy" at
all).
But on a second though, even users can be faced with such hashes, for
example due to errors in the archive which can be temporarily
inconsistent or because their package manager is incomplete WRT
dependency solving. In that case, the md5sums pop up in error messages
and, I believe, they will confuse sensibly the user.
Hence, the proposal is taking a checksum of all the checksums, which
will of course increase the probability of collision, but still keep
them at a reasonable level, and improving seriously upon the current
status where dependencies mean nothing in terms of OCaml linkability.
If you think the quoted paragraph should be rephrased to better
represent what you're doing, just let me know.
> (I assume dh_ocaml can generate dependencies automatically by
> examining the *.cmo & *.cma files contained in the final binary
> package?)
Yep, that's the idea, but also including native code objects.
BTW: did you notice that in OCaml 3.11 there is now an executable to
inspect also implementation assumption for native code objects? AFAIR
Fedora mechanism's was only based on bytecode assumptions. We plan to
support both kind of assumptions and I guess it would make sense for
Fedora too (even though you will need to have an extra namespace in
deps to differentiate bytecode vs native code assumptions).
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
Attachment:
signature.asc
Description: Digital signature