Note: native depsolver integration is not (though related to) native package manager integration! This is about the usage of yum and apt to solve dependencies.

Problems

1. Two major dep solvers: apt and yum Write wrapper programs that can use apt and yum. Shouldn't be too hard.

2. Each distribution has different names for packages. Extend skeletons. Let it print all possible package names. For example, the skeleton for gtkmm:

   [NativeNames]
   # $1 is interface version
   if [[ "$1" = "3.0" ]]; then
       # gtkmm 2.4
       echo "gtkmm24 libgtkmm-2.4-1"
       # gtkmm24 is Fedora's name, libgtkmm-2.4-1 is Debian's name
   else if [[ "$1" = "2.2" ]]; then
       ...etc...
   fi
   

   Autopackage will then search the native depsolver's list for one of those packages, and install all exact matches (not substring matches; we don't want ).

---

MikeHearn?: It may be worth repeating a pattern we've used elsewhere, if a code section like [NativeNames] is missing then autopackage provides a default which reads metadata. Some dependencies may not change their native name much. Imagine an Inkscape extension installed via autopackage, which then resolves a native inkscape package. On what distro would Inkscape not be in a package called "inkscape"? Other cases, like GTKmm or libstdc++ are much more complex.

In some cases, there may be well known conventions. For instance, if we have a library XXX, on Debian it'll be called "libXXX0" for interface versions 0.x and so on - when the autopackage and native metadata match, that can be exploited.

On the other hand, this can all get rather tricky rather quickly, and is no replacement for a real platform IMHO.

Jan-Nik: PackageKit? could be used to solve the first problem: http://www.packagekit.org/