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

Reply via email to