[cldp] Re: issues
- From: "Benjamin Rich" <benjamin.rich@xxxxxxxxx>
- To: cldp@xxxxxxxxxxxxx
- Date: Wed, 19 Apr 2006 13:29:48 +1000
Karol,
On 4/19/06, Karol Pietrzak <kap4020@xxxxxxx> wrote:
> 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.
Agreed, I think I'll go ahead with this.
> > 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).
Well this seems much better, obviously I misunderstood the docs. But
even so, how can autopackage grab a required package from the
underlying distro if it isn't there? If it can't do this, maybe we
should concentrate on writing a backend system that would allow this,
pitch it to the autopackage people?
> Question: could you elaborate on your maintainer domains point?
It seems like a confusing idea to me. I suppose it brings some
conceptual order to naming autopackages, because if you want to check
the name of the libao autopackage dep, for example, you go to
libao.com (or whatever) and they'll have info on what they call it
there, since they control the domain for it. But what about when
people start offering up alternative versions of packages and use
their own domain roots? And does autopackage look up a package domain
and expect to find a server there serving out the autopackage
depdendency, or does it go to autopackage.org and use their system to
find the file?
Anyway I freely admit I don't understand this side of things properly,
I'll go back and read up on it more soon. It's obviously a workable
idea if it's come this far, but it seems to me that the first
mechanism that the package should be using for grabbing dependencies
is the distribution, *especially* for ubiquitous libraries, because
that's the entire point of having a separate packaging system - for
managing system apps and libraries.
> > - 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?
Ah, well, if they already have it in the works, no doubt they've got
things further along than we could offer.
The thing is, bricklayer relies on the concept of the LDBK, so you can
request a general dependency, and have it grabbed locally. Integration
with the distro, as such, isn't really part of it - the integration
level is very basic, bricklayer would just know the commands to
install a package.
To me, the idea of doing any part of the system package managers job -
upgrading an already installed package - seems like a bad approach.
The autopackage thing should be separate from the system, it should
not try to enhance or work with it. The whole concept as I see it is
that gaim etc. should not be installed by the distribution - ideally,
the distro would only install system stuff, all user applications
would be put in by autopackage.
Anyway this is all vastly complex stuff, I think I need to read up a
lot more on autopackage first before I can give this a meaningful
appraisal. Since we're going in this direction, I will find out more
first before committing any more opinions =P
> > - 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
Will do.
> P.S. Are there any chances of getting a Track installation on the webpage?
> Free Wiki included. :)
What exactly is track btw? =P
I'll check it out, the new host (which I've just moved over to in the
last hour =) seems to only provide the usual, phpbb forum, mediawiki,
etc. - I'll see if we can get a Track installation on there, probably
manually. Shoul be a breeze since we now have shell access and no more
cpanel crap to worry about.
-Ben
> --
> Karl Pietrzak
> kap4020@xxxxxxx
>
>
>
Other related posts: