On 7/27/06, André Detsch <[EMAIL PROTECTED]> wrote:
While dependencies for Recipes depend only at the source code itself, dependency for a binary package are, most of the time, dependent on the environment the package was compiled.E.g., a recipe can be compatible with Glibc [2,), but, once a package is compiled on a Glibc 2.4 system, it depends on Glibc [2.4,). {or Glibc [2.4,3) } In order to avoid the need of preparing by hand a Dependencies file each time a binary package is built, it would be nice if we can describe some general rule for recipe-to-package conversion of the Dependencies file. Here is a first raw idea: Each program could have a rule file inside Resources. Once a package is 'Compile'd, each program listed at the recipe Dependencies file is verified, and, based on its rule, a line to be added at the package Dependencies is prepared. The rule would give general information about back/forward compatibility, and could differentiate major, middle and minor numbers that compose a program version. Here, either a regular expression or a more high level syntax could be used. For example: One rule can state that packages compiled against gtk+ X.Y.Z depend on a gtk+ with the same major-number (X), and with a middle at least equal to Y. GTK+ [X.Y,X+1) In the case of Glibc, the generated dependency would be something more like Glibc [X.Y.Z,X+1) So, I guess the rule file could be composed of a optional regular expression (the default regular expression would be the one that returns 'n' fields, corresponding to the version number splitted on each '.') and a string describing how to put those fields together on the dependency line. Notice that at this step, we can perform even automatic generation of dependencies like libstdc++ as an option to GCC. GCC [X.Y,X.Y] || Libstdc++ [X.Y,X.Y]
I like this. My feeling about sorting out dependencies is that we can't rely on general schemes for handling version numbers, but each project defines their own conventions. What I like about your proposal is that (again, in my gut feeling) these per-project conventions can be mostly relied on. With your X.Y.Z scheme we could 'encode' these conventions in recipes and that could largely automate the conversion process, in a documented (and still overridable) way. -- Hisham _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
