Having submitted several binary packages and had some chats on IRC with users trying to install the same packages I came to the conclusion that we need to rework the dependency scheme a lot.
First I'd like to change dependencies to be none recursive. Now we list dependencies of dependencies for an application. For example QMPDClient depends on Qt which depends on Expat, but QMPDClient doesn't depend directly on Expat, still Expat is listed as a dependencies of QMPDClient. I think it's better that CheckDependencies find out, when building the dependency tree, that Expat is needed if it's going to install Qt as a dependency to QMPDClient. This applies to Recipes as well as Packages, basically the information in BuildInformation, which a basic Dependencies file is based on. Secondly I want a new dependency scheme for binary packages. Below is a draft I've been thinking about: For each needed library file a corresponding file is created in Resources/LibraryDependencies, with the contents of which *current* application provides that file, e.g. ]cat /Programs/QMPDClient/1.0.8/Resources/LibraryDependencies/libQtGui.so.4 Qt 4.3.1 (qmpdclient needs libQtGui.so.4, which is provided, on this system, by Qt 4.3.1) When the package later is installed on another system, CheckDependencies (or similar) checks what libraries are needed and if they are present in $goboLibraries or $LD_LIBRARY_PATH (if set). If it's not, the script will try to get the file $packageMirror/official/LibraryDependencies/libQtGui.so.4 which includes a list of all official applications having this file and the script will try to choose one of those applications. If all fails, the script reads inside the file in the Resources directory to find out what application that guarantees to have that file to either try and install it, or to alert the user about missing dependency. (Some sort of) Pseudo code: for i in /Programs/QMPDClient/1.0.8/Resources/LibraryDependencies/* do if exists $goboLibraries/$i then continue to next get $packageMirror/official/LibraryDependencies/$i and decide on package to install if above fails or no-web look inside $i and try to install that package else alert user about missing dependency done The reason for this new scheme is that while our current dependencies scheme might work for recipes, when one builds from source, it's not always that simple with binaries. At the same time this scheme can handle badly written dependencies as it's much more robust. This is just a draft, but there are two major points I'd like to adhere to: 1) Packages should be self contained - no information about a package should be stored outside of the package. 2) Most of these things should be doable without the tools, hence plain text files. -- /Jonas Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel