[cldp] Re: issues

  • From: Karol Pietrzak <kap4020@xxxxxxx>
  • To: cldp@xxxxxxxxxxxxx
  • Date: Tue, 18 Apr 2006 23:03:55 -0400

On Tuesday 18 April 2006 07:37, Benjamin Rich wrote:
> Hi all,
> I'm having some second thoughts about the whole
> appfolder/bricklayer/autopackage drama. Here was my train of thought
> in making bricklayer:
> 'Appfolders are cool because they make applications simple and
> entirely relocatable; let's implement them in linux; but we can't
> include depedencies like GTK etc. in applications, so some deps will
> have to be resolved outside; so we'll make a layer to get the distro
> to do this.'
> Seems simple, doesn't it? But now I'm thinking:
> '...okay so we have a system in place to resolve dependencies; but
> there are other things which can't stay in the appfolder, we have to
> install menu shortcuts etc; that can be taken care of by xdg tools,
> but then we have to clean up when the app is deleted; so it has to be
> uninstalled through bricklayer; oh well that's not too bad, but it
> means the app isn't totally relocatable, has to be
> installed/uninstalled; hmm...; oh no and things like man files have to
> be put in the system area...'
> Things started to fall apart...
> 'hmm maybe I could have the appfolder and make symlinks from
> /usr/share/man t /apps/application.app/man/manfiles or something... no
> but then i'd have to remove that when the thing was uninstalled....'
> So in short, it's looking shakey. I realise the main reason why I
> wanted to implement appfolders was for reason 1 - that then apps on
> linux could be relocatable. But this simply isn't possible because of
> system depdencies and a host of other things.

Off the top of my head, after watching the technical issues involved with 
Autopackage, I think that's the right choice.

Who knows, maybe in a few years things will simpler from a technical point of 
view, and appfolders will be the best option.

> Therefore I'm thinking of moving the CLDP officially to autopackage
> packages as the default standard, since they are well extablished and
> seem to be the best 'universal' standard around.
> But there are still problems to ponder:
> - The way autopackages handle dependencies is to have an app developer
> name them by domain/appname (eg. 'some other developer's user-defined
> category/application name'), and grab them off the net. Said
> dependency is also an autopackage, and installs via this method again.
> This tramples all over the distro's inbuilt package management system,
> and I don't think it's a good idea. Also, how are people supposed to
> keep track of maintainer domains?

An autopackage's dependencies are not other autopackages.  The idea is that a 
dependency can be fulfilled in ANY way, whether it be from a distribution's 
RPM, self-compiled source in /usr/local, or whereever.  Downloading an 
autopackage from the web is just another option.

So, for example, a dependency on SDL.org/SDL in an autopackage is fulfilled by 
checking whether the SDL library actually exists (i.e., checking for 
libSDL.so.1 or whatever).

Question: could you elaborate on your maintainer domains point?

> - Could we alter autopackage and make a version where dependencies are
> resolved via bricklayer? This would be ideal I think, but how to go
> about it? Should we even suggest the idea to the autopackage people
> that deps be resolved via the distro?

Native package manager integration is in the works; in the planning phase to 
be more specific.  For example, a user might have Gaim installed by their 
distribution (say, Ubuntu).  Then, they want to upgrade their Gaim using an 

The idea is that the Autopackage runtime should interface with the DEB system 
and uninstall the Gaim DEB before installing the new files from the 
Autopackage.  Of course, the Autopackage runtime would also have to interface 
with RPM, and it would be great if it worked for Solaris package system too.

Do you think this process could be improved using the BrickLayer approach? 

> - What if we removed BrickLayer/LDBK completely, and just concentrated
> on the other tools, and getting along with xdg/autopackage? Would it
> be good to be trying to integrate with autopackage, ie. be at the
> mercy of the decisions made by another project? How do they stand on
> using freedesktop.org stuff?

Heh, the Autopackage folks would LOVE it if every distribution supported XDG 
today.   Lots of problems would immediately disappear.  But, truth be told, 
lots of distributions don't even support the XDG specs properly TODAY.

Absorption of the Portland project by distributions as soon as possible would 
be a godsend to us and to the Autopackage project.

In general, the Autopackage team is very user-oriented.  Everything that makes 
life hard for users (e.g., incompatible gcc ABIs, incomplete /usr/local 
support, incorrect specification implemention, etc.) is frowned upon.

Feel free to post to the autopackage-devel mailing list about your concerns.  
I'm sure you'll get good responses.

You can check out the mailing list archives too:


P.S. Are there any chances of getting a Track installation on the webpage?  
Free Wiki included. :)

Karl Pietrzak

Other related posts: