On 10/24/07, Michael Homer <[EMAIL PROTECTED]> wrote: > 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.
Yes, the example is correct. For HAL and HAL-Info, we have that HAL is a 'build dependency' for HAL-Info, but HAL-Info is a 'runtime-only dependency' for HAL. It occurs to me now that everytime we talked about optional dependencies we end up talking about use-flags as well as we never get anywhere. One thing we could do would be to implement extensions to the Dependencies format _first_ and worry about use-flags later. How about something adding a bracketed list of tags, like: Foo >= 1.0, < 2.0 [build-only, optional, i686] Bar >= 0.3.5 [runtime-only, !ppc] (I thought about dropping the "-only", but the fact that adding [build] would implicitly disable [runtime] looked a bit weird, as it seemed that a regular dependency implictly meant [build, runtime]. Anyway, opinions are welcome.) -- Hisham _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
