On 12/6/06, Hisham Muhammad <[EMAIL PROTECTED]> wrote: > > > And who is going to figure out the dependencies for each of the 200+ > > > subrecipes? Most importantly, how? Removing Dependencies from > > > subrecipes was André's idea, which I agreed with. He may be able to > > > provide more insights on the rationale for this decision. > > > > > There are not that many dependencies. The complete meta recipe Xorg has 9 > > dependencies. If you look at the separate sub packages, i.e. Xorg Libs, > > they have about 3 depenndecies each. Of cource they depend on earlier > > parts of the Xorg meta, but we can't check on that atm, as we don't know > > what's installed in the meta directory. > > The "how" problem is finding out which of those 9 should be present on > each of the 200+ subrecipes (and if subrecipe dependency was > supported, which other subrecipes it depends on). Drawing the complete > dependency graph for all bits and pieces of Xorg may be complicated.
I also have had numerous hours spent on Xorg compilation, and many of the problems I had _were_ related to the 3 level scheme (Xorg -> (Xorg-Data, Xorg-Server, Xorg-Proto, ...) -> libxfoo..). In fact, having the components too much spread makes things hard to maintain. Looking at Hisham's patch commited some hours ago, it looks like "recovering" from bad compilations is now better handled. > Like I said in the other thread, maybe this _should_ be possible, and > that the recipe for Xorg is over-complicated. Maybe breaking Xorg in, > I don't know, 5 or 6 pieces is the solution. Then it wouldn't be a > pain to rerun each meta and they could have dependency info related to > each other. But I'd leave that decision to André, who's working closer > on the Xorg recipes. The problem will still exist: "what if a final 'leaf' in the meta-recipes tree fails? how do I recover from that without recompiling everyone listed in the include array?" It's just splitted into smaller pieces, but I don't see it becoming less problematic. Actually, it becomes more harder to maintain, especially when thinking about the multi-architecture support. It's way better to have a centralized list of includes, and possibly NewVersion turns more friendly. Wouldn't it be better to just certify that the recipes are sane, submitting revisions otherwise? > Another thing that comes to mind is that maybe Compile should (ask > to?) delete the results of a failed compilation from /Programs. Any > thoughts on that? Better ask. Sometimes Compile just fails at SymlinkProgram time (ok, we shouldn't have broken recipes, but sometimes it happens), and it's fine to run that by hand before fixing the recipe. > > As for 'Compile --app-name --app-version -keep', I think that the sub > > recipes should emulate this by specifying 'part_of_name=Xorg' and > > 'part_of_version=7.1' inside the recipe (the variable names could be > > discussed). > > Ok, I think that's feasible. Only problem is that one version of a > sub-recipe may be used by different versions of a meta-recipe (for > example, I think some pieces of Gnome may not be updated on each point > release). Don't know if it happens in practice though, but it's > something to think about. Hmm, why add two new variables? Can't these be taken from Dependencies somehow? Anyways, it's probably fine to run an upgraded version of, say, libxrandr, on both 7.0 and 7.1. I don't like too much the idea of growing even more our 'instruction set'. > > Anyway I feel like we should approach this some other way as I'm stuck on > > that we don't know what files are installed in the meta directory. > > As a recipe debugging aid, I agree that having the info of what's > already built can help. I don't like the idea of using this to > micromanage contents of the resulting package later. Can't we run Compile with some kind of logging enabled? Something like this: ] Compile --log Xorg ... Compilation failed. See '/System/Variable/tmp/Compile-Xorg-error.log' for more information. ] cat /System/Variable/tmp/Compile-Xorg-error.log bigreqsproto--1.0.2 compositeproto--0.2.2 damageproto--1.0.3 dmxproto--2.2.2 evieext--1.0.2 fixesproto--3.0.2 fontcacheproto--0.1.2 One could use this information in addition to Hisham's '--start-at' patch, passing fontcacheproto as the starting point to Compile. What do you think? -- Lucas powered by /dev/dsp _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
