On 12/6/06, Jonas Karlsson <[EMAIL PROTECTED]> wrote: > I don't like not beeing able to control the sub applications in a meta > recipe, or rather update the main application without having to recompile > the complete meta recipe, so I have some ideas on how to solve that and > would like some feedback. > > 1) Install sub apps in their own directory and (sym)link them into the > meta directory > * Easy removal of sub apps. > * Hard to remove the complete application > * Could have the drawback of maybe overpopulating /Programs (this approach > on Xorg would nearly double my package count). > * Maybe hard implementation in fibo sandbox > > 2) Install sub apps in a sub directory in the meta directory and place > (sym)links in the corresponding directories (bin, lib etc) > * Easy to remove a sub app. > * Easy to remove the complete application. > * Maybe hard implementation in fibo sandbox > > 3) Install sub apps in the meta directory, but create directories/files, > in a directory in Resources, which contains file listings of the sub app. > * Easy to remove the main application > * Hard to remove old sub apps > > 4) Install sub apps in the meta directory and create a file/directory that > contains sub app name and version > * Easy to remove main application > * Impossible to remove sub apps > > What I mainly are looking for is a way to update the main application on a > sub app basis. All the suggestions above do that, but they have other > qualities as well.
Ok, let's think broadly about the general problem. Meta-recipes were never designed to have sub-parts managed individually because they were conceived as a way to build _one_ app out of many parts, not as a way to put many apps under the same prefix (which would take us back to square one, kind of like "/usr"). [Yes, I know about the argument for compiling everything to the same prefix -- it's in the plans but it's something to be done from the ground up; another discussion.] The fact that micromanagement within meta-recipes has never been a problem until the new modular Xorg probably says more about the structure of Xorg than about the design of meta-recipes. When Xorg was first converted from the monolithic build to the modular one, we tried making separate /Programs entries for the various parts, but some dependency chains made that complicated, so we ended up going for the single /Programs/Xorg entry. Like /Programs/KDE was broken in subparts, maybe it's a good idea to look into breaking /Programs/Xorg again. Maybe the problem is not that we need to micromanage subrecipes, but instead that we need to look at the granularity of our metarecipes. This brings us to the original design of GoboLinux: Instead of adding stuff to fix an apparent problem, maybe we can organize things better so that the problem does not happen in the first place. A famous quote comes to mind: "It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away." -- Antoine de Saint-Exupéry As for the options given, I'm not a fan of any of them. I'd like to hear the opinions of the other devs in this issue, but I think all of them make the overall structure of /Programs more complicated and, like I said, maybe it's the wrong way to look at the problem. Something vaguely like 1) is what we used in the earliest days before the share/Shared distinction. A related, but not the same, problem is that debugging the compilation of huge metarecipes (by that I mean the Xorg metarecipe which is the only huge one) is cumbersome. For that problem, I think an additional Entry option for Compile, --start-at (to be used only with --lazy) could solve the problem, so that one could specify which sub-recipe to start at when rerunning Compile on a metarecipe. -- Hisham _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
