On Thu, Feb 26, 2009 at 04:11:58PM +0000, Richard Jones wrote:
> Fair enough, although I have to say that users never see them. Yum
> will bail much earlier on if it cannot download a consistent view of
> the archive.
Can you explain this a bit more, I'm working on package managers and
dependency resolution within Mancoosi [1], and I'm kinda interested in
the topic. First of all let's be clear with inconsistent repository,
of course we are interested in repositories in which there is at least
*a* way (not necessarily compatible with a given user installation) to
install all shipped packages.
That's what EDOS provided and which is used in Debian [2]: efficient
detection of uninstallable packages. In that case, you can bail out
earlier, but you need to explain the problem to the user: how can you
do that hiding checksum details? You just use "real" package names and
hide the details or what?
But then, you of course have the problem of consistent repositories,
where a package cannot be installed due to a real conflict induced by
OCaml checksums. For example you can imagine two pairs of OCaml
libraries: <libA1, libA2>, <libB1, libB2> where all four libraries use
a module "M" with consistent assumptions within A1/A2 and B1/B2, but
inconsistent across pairs. Yes, it would be a shame, but what you tell
to the user if she has installed libA1/A2 and she wants to one of
libB1/B2?
And finally, all this does not solve the problem for repository
maintainers (which will be our release team), they need to be faced at
times with inconsistent repositories and having shorter ABI
identifiers would be a plus for them. This kind of "users" does not
necessarily use a package manager when inspecting dependencies.
[1] http://www.mancoosi.org
[2] http://edos.debian.net
> Anyway, the much bigger problem is ocamlobjinfo and some "extra"
> modules that you'll see. Currently we hard-code a list of modules to
> ignore. At the moment that list is:
Actually, I've a memory fault (in my head) on this, I remember that
when I first implemented dh_ocaml/ocaml-md5sums (possibly 2003) I've
stumbled upon a problem which made me to hide some modules of CamlP4,
but I don't remember the reason. Is it related to this? Can you please
explain why you have to ignore sub-modules?
> I'm also interested to know if you find a way to get ocamlobjinfo to
> display submodules. I even tried looking at the .cmo file format
> but couldn't find out how to derive the module/submodule
> relationship between modules.
I divert this question to Stephane, he studied the internals of that
stuff :)
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