[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
Autopackage.
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:
http://news.gmane.org/gmane.comp.autopackage.devel
P.S. Are there any chances of getting a Track installation on the webpage?
Free Wiki included. :)
--
Karl Pietrzak
kap4020@xxxxxxx
Other related posts:
