2006/12/7, Lucas C. Villa Real <[EMAIL PROTECTED]>: > 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. > The problem is that with Xorg you had to restart the compilation every time it failed. If the recipe were split so you could build component for component you would get to build problems much faster, as for every error you only had to rebuild that component.
> > 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. > I thin kthat Hisham thought of compiling each piece by it self, so one would have "Xorg-prot", "Xorg-lib" and so on instead of one big "Xorg" meta. I think this is a good idea. Then one "only" have to recompile about 30 apps in average if one leaf fails. > 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'. > The variables are used to force (ask) an installation directory for apps that should go into the same directory. This isn't something that can be read out of the dependencies. I thought of the version and maybe it doesn't have to be mandatory. Another way, instead of adding new things to the instruction set, is to redo meta recipes. :) > > > 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. > Well, suggestion 4) in the "Installation of meta recipes" thread does add this info, just for aiding in what's been built. Part as debug aid, but also to help having dependencies in the sub recipes, so one knows that a particular dependency is installed. > 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? > It could be useful, but I would also like some information on why the compilation failed. Perhaps the crux of the matter is: I don't like the idea of meta recipes. To me they're not representative for GoboLinux. But I have not created it so I really don't know how it's meant to be. I use GoboLinux because it gives me full control of the system, but that is compromised in meta recipes. Instead I believe that each app should have it's own directory, even if it's part of a bigger app. But maybe that's not doable until Compile is rewritten to support /System/Links as prefix. -- /Jonas _______________________________________________ gobolinux-devel mailing list [email protected] http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
