On 10/23/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote: > I've just realized that my recent commits created (at least) one new > dependency loop: GTK+ -> Cairo -> LibRSVG -> GTK+ > How shold we handle these loops? By declaring LibRSVG as optional > dependency for Cairo we can weaken the loop, but since we don't > support such flags yet... > The problem exists primarily for Freshen and cyclic graphs, but > there's a problem with Compile as one have to bulid in the right order > (and rebuild Cairo once LibRSVG is built). It's only a annoyance with > InstallPackage as the user will get the same question twice. > How should we handle these cyclic dependencies? For Freshen's part, at least, it can probably be dealt with by more intelligent dependency handling, but I'm not sure how to go about that yet. At least for the cases that do have a well-defined and usable order, and ignoring the bootstrapping situation. I think that could be satisfied by stripping the dependencies that are already satisfied and allowing the rest to progress as normal.
The problem really arises when there are circular dependencies that aren't already satisfied in part. The manual solution to that is probably to upgrade to an intermediate version of one of them that does allow some of the other dependencies to be satisfied, and continue until the tree is resolvable. I don't know how to manage that automatically; I would really rather they didn't exist. I think this is the kind you're talking about here. So long as the version requirements make it possible to resolve, Freshen should be able to deal with it (normative should, it might not actually do it), provided that the user has a sufficiently recent version of GTK+ installed (meaning, they meet the dependency for the newest LibRSVG). If they don't, diagnosing the problem and telling them what to do about it would be nice. Fixing it magically is theoretically possible but practically messy. Another situation is that in some cases (HAL and HAL-Info are one, I think), what really matters is that they're both there at the end. I don't think HAL actually requires HAL-Info to build, but the reverse might be true (if not, it was a bad example, so substitute another). Portage allows a sort of reverse dependency, where a package specifies that it requires something to be installed -after- it. Being able to specify that kind of relationship in the dependencies would be helpful, I think. I think there are other cases too, but I don't remember them off-hand. There are probably better ways of handling those as well, I'm just throwing out ideas at the moment. -Michael _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
