Some future plans
Matthias Klumpp
I'm back from holiday now, so I can continue the Listaller development. I
did some code- and design review the last days and decided that most parts
of the API really suck. There are a lot of improvements needed, which I
will do the next days.
At first I will do some renaming: The libinstaller will now be known as
liblistaller. Libinstaller is not a good description of what the library
does. I will also rename the listallerd program (our DBus-Daemon to perform
actions which require privileges) to listallhelperd. If the daemon is known
as "listallerd", someone could think it covers the whole Listaller
functionality, which is not the case.
I'm also planning a PlugIn-System for Listaller. At time, PackageKit is
used to interact with the package managers, but especially in searching for
files it is not fast enough. So I'm thinking of moving all package manager
interaction to a plugin-system. So we can create a native APT or yum or XY
backend for Listaller. If the backend is not found, Listaller will fall
back to PackageKit. It will also be possible to enhance GNUPG-Support via a
GPGMe-PlugIn.
Before I start anythink of this, a lot of maintainance and cleanup tasks
are necessary. Also it would be great if we could make apbuild work again.
(Compiling fails at time)
We also need a good solution for installing dependencies which aren't
found in the repos. The current way (fetch them from deb packages and
install them in $INST) needs some re-thinking, maybe we can learn something
from Autopackage.
Regards
Matthias
Jan Niklas Hasse
On Sun, Aug 22, 2010 at 6:24 PM, Matthias Klumpp <matt...@nlinux.org> wrote:
> I'm also planning a PlugIn-System for Listaller. At time, PackageKit is
> used to interact with the package managers, but especially in searching for
> files it is not fast enough. So I'm thinking of moving all package manager
> interaction to a plugin-system. So we can create a native APT or yum or XY
> backend for Listaller. If the backend is not found, Listaller will fall
> back to PackageKit.
Why not rather improve the PackageKit backend?
> Before I start anythink of this, a lot of maintainance and cleanup tasks
> are necessary. Also it would be great if we could make apbuild work again.
> (Compiling fails at time)
I committed a fix a while ago to the Autopackage SVN, which should work :)
> We also need a good solution for installing dependencies which aren't
> found in the repos. The current way (fetch them from deb packages and
> install them in $INST) needs some re-thinking, maybe we can learn something
> from Autopackage.
The problem with using deb packages is, that they might only be binary
compatible with debian distrubitions, etc.
Autopackage's approach is to use an Autopackage for the dependency, too.
Matthias Klumpp
wrote:
> Hi Matthias,
>
> On Sun, Aug 22, 2010 at 6:24 PM, Matthias Klumpp <matt...@nlinux.org>
> wrote:
>> I'm also planning a PlugIn-System for Listaller. At time, PackageKit is
>> used to interact with the package managers, but especially in searching
>> for
>> files it is not fast enough. So I'm thinking of moving all package
>> manager
>> interaction to a plugin-system. So we can create a native APT or yum or
>> XY
>> backend for Listaller. If the backend is not found, Listaller will fall
>> back to PackageKit.
>
> Why not rather improve the PackageKit backend?
with the PackageKit team about it later. Creating an extra PlugIn system
will only be the last option, because then Listaller will duplicate
functionality of PackageKit.
>> Before I start anythink of this, a lot of maintainance and cleanup
tasks
>> are necessary. Also it would be great if we could make apbuild work
>> again.
>> (Compiling fails at time)
>
> I committed a fix a while ago to the Autopackage SVN, which should work
:)
Great! I applied the patch at the Listaller master branch too.
>> We also need a good solution for installing dependencies which aren't
>> found in the repos. The current way (fetch them from deb packages and
>> install them in $INST) needs some re-thinking, maybe we can learn
>> something
>> from Autopackage.
>
> The problem with using deb packages is, that they might only be binary
> compatible with debian distrubitions, etc.
> Autopackage's approach is to use an Autopackage for the dependency, too.
To create a solution which supports a wide variety of different
applications, we need to provide *a lot* of packages... We need a server
which builds the dependencies or puts them together from binary
distribution packages (Fedora/Debian). I think this will be a good way.
I'll talk to the ZeroInstall and Klik guys if they support it too, because
we will need a server infrastructure for this. (And I will do a few tests
if this idea is possible to realize)