[cldp] Fwd: resolving dependencies through the distro?

  • From: "Benjamin Rich" <benjamin.rich@xxxxxxxxx>
  • To: cldp@xxxxxxxxxxxxx
  • Date: Wed, 19 Apr 2006 21:28:20 +1000

Hi all, sent this to autopackage-dev list
(autopackage-dev@xxxxxxxxxx), thought you'd be interested. Let's hope
they give some feedback.


---------- Forwarded message ----------
From: Benjamin Rich <benjamin.rich@xxxxxxxxx>
Date: Apr 19, 2006 9:24 PM
Subject: resolving dependencies through the distro?
To: autopackage-dev@xxxxxxxxxx

Hi all,

A week or so ago I started a project called the Common Linux Desktop
Platform, which aims to make some cross-distribution tools that make
it easier to install desktop applications in a consistent way
regardless of your underlying setup. I discovered that there are quite
a few of these projects, not least of which being the portland project
and freedesktop.org standards project, and of course autopackage.

Part of the CLDP (still there on the site, linux-platform.org) was
going to be an implementation of pseudo appfolder-style applications
with a thing called 'bricklayer' to handle them. A dev would make
their software, compile a binary version, install it all into one
directory called application.app/, tar it and distribute it with a few
config files inside. These files would stipulate things like 'system
dependencies', things which couldn't be included with the app for
various reasons, like CUPS or GTK (all local resources though, like
sounds or images, themes, local libraries etc. would be packaged in
the application.app folder).

Each distribution would have a tailor-made version of bricklayer which
could read the dep files in an appfolder, where simply things like
'GTK-2' or 'CUPS' or 'LIBAUDIO-1' would be specified, and then use the
local distribution to get specific packages fulfilling these deps (eg.
gtk+-2.0-ubuntu-6.06+20060214.deb for GTK-2 or something).

However I have now come around to the point of view that
appfolders are stupid, and am now going to endorse autopackages as
part of this project instead. Mike already talked to me on this line in a
thread in xdg, and I now agree it's a waste of time creating yet
another new standard.

Nonetheless I am still intrigued with the idea of using the local
distribution to fill dependencies, which was the point of bricklayer.
I know that autopackages can check
for certain deps already being installed, but what of using a
distro-specific backend to establish ones which aren't?

It seems IMHO a conflict to create a system like autopackage, not
intended to replace apt/RPM/portage/yum/etc., designed only for
installing user application like gaim, firefox, etc. to fulfill system
dependencies over the top of what the distribution might want to do.

Autopackage may already be capable of this, or this might be in the
pipeline, I apologise if I've misinterpreted the docs and I'm missing
something huge, I haven't had enough time to go through them
completely (have bronchitus at the moment for a start). But would
anyone say this was interesting or worthy of devlopment?

Is there anything in place in the autopackage installer which allows
different methods to  resolve dependencies to be written in? Maybe the
CLDP could work at making an autopackage compatible backend which
grabs library dependencies through a given distro?

Please give me your thoughts,


Other related posts:

  • » [cldp] Fwd: resolving dependencies through the distro?