On 10/25/07, Hisham Muhammad <[EMAIL PROTECTED]> wrote: > 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.) I like this a lot. It's flexible and it allows for covering all the special cases that come up. It also keeps everything in one place, which I like more than having separate files for different kinds of dependency. It would also allow more complicated entries like "Foo >= 1.0 on i686, Foo >= 1.2 on ppc" to work by just adding multiple lines with arbitrarily complex settings.
>From the perspective of graph cycles in Freshen, they'd be avoided by injecting the runtime dependencies as depending on the base program, but not vice-versa, so they'd tend to end up immediately afterwards in the ordering. The DBus/Xorg-type situation probably wouldn't be resolved directly by that, but cleverer dependency handling can probably reduce that problem to an occasional minor inconvenience. -Michael _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
