On Sat, 25 Aug 2007 03:43:44 +0200, Michael Homer <[EMAIL PROTECTED]> wrote:
> On 8/25/07, Jonas Karlsson <[EMAIL PROTECTED]> wrote: >> 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. > <snip> >> 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. > That sounds fine to me too. I'm not sure about the network-dependence, > though; it seems it would involve a lot of fetching. Building a tree > for the entire system could mean fetching every one of them, and the > LibraryDependencies/* files aren't long-term cacheable. I know, and this is the weak point of this implementation, from that perspective - speed. Otoh it's much simpler and wouldn't require any "outside" application. >> 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. > I hope that means "no information about a package should be stored > ONLY outside of the package"; otherwise resolving dependencies > recursively will be impossible without actually fetching all the > packages involved. We'd still need to keep dependency files for each > package around so they could be resolved in advance. Yes, maybe that was a bit unclear. What I meant was within a system. That we extract information from a package tarball and place it on a server is just for help and is not required for dependency resolution - one can still download the package tarball and look inside that. -- /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