Re: Intergrating autopackage in Starez

On 9/2/07, Hylke Donker <[email protected]> wrote:
> I just found that when I ran the autopackage from the terminal, I got this
> output:
> /tmp/autopackage.106989164/meta/@autopackage.org/mkapspec:0.4/apkg-prep-install-script
> : line 80: _checkEULA: command not found
I think you're getting that because the mkapspec package was
(accidentally) built using the SVN version of Autopackage instead of
the latest released version.

Try installing one of these packages:
* http://ftp.sunsite.dk/projects/autopackage/packages/Visual%20Dependency%20Walker%201.2.package
* http://ftp.sunsite.dk/projects/autopackage/packages/mkapspec-0.4-2.x86.package

Or try one of the packages on http://autopackage.org/packages

Sorry about that!
- Taj

>
>
> On 9/2/07, Hylke Donker <[email protected]> wrote:
> > Also, when I tried to install the apspec generator with the .package file,
> I got the following error:
> > Error: Unable to prepare package APSpec File Generator.
> > And then I was unable to close the autopackage GUI.
> >
> >
> >
> > On 9/2/07, Hylke Donker <[email protected] > wrote:
> > > I've started reading some docs, and as an exercise I thought it would be
> a good idea to make a simple package, but I have came across a problem.
> According to the docs, autopackage comes with a bunch of standard
> skeleton-files. But where can I find them?
> > > And what is the following code for(from the meta section)?:
> > > Repository:
> http://www.mysite.org/downloads/myproject.xml
> > > Does that xml-file contain the packages that can be retrieved when a
> test in a skeleton file failed?
> > > I hope you answere my questions.
> > > Thanks in advance,
> > > Hylke
> > >
> > >
> > >
> > > On 8/31/07, dazjorz <[email protected] > wrote:
> > > > On 8/31/07, Isak Savo < [email protected] > wrote:
> > > > > 2007/8/30, Hylke Donker <[email protected]>:
> > > > > > Hello,
> > > > > >
> > > > > > Anyway, to get back to the subject of this e-mail, Starez needs to
> be
> > > > > > able to install games on a distribution independent way. We (me
> and
> > > > > > Sjors, the other Starez developer) have been debating this alot. I
> > > > > >  thought it would be best to make a simple archive with all the
> > > > > > dependencies included, and Sjors thought it would be best to have
> two
> > > > > >  packages for every game, one that contains the game files, and
> one
> > > > > > that contains several scripts (for installation and configuration,
> and
> > > > > > things like dependency checking).
> > > > >
> > > > > I'm not sure I understand why you'd need two packages. One package
> can
> > > > > do what you ask for (autopackage is the proof) and it's easier for
> the
> > > > > end user.
> > > > > Inside the actual package, theres a separation of "game files" (we
> > > > > call it payload) and "installation and configuration scripts"
> (support
> > > > > files).
> > > >
> > > > It's not easier for the end user, since he will use an installer that
> > > > will do everything for him. Next to that, the two packages idea was
> > > > primarily before we came up with autopackage, so the scripts would be
> > > > apart from the binaries and game data files, which would be easier and
> > > > more enhancable.
> > > >
> > > > >
> > > > > > What we would like to know is: Will autopackage be a good solution
> for
> > > > > > our problem?
> > > > > > Is it possible to intergrate autopackage in Starez or a Starez
> > > > > > installer for installing games?
> > > > > > The main breaking points in our installation discussions were
> > > > > > dependencies and configuration, how does autopackage handle these?
> > > > > > And if it's possible to intergrate autopackage in Starez, how will
> we
> > > > > > go about that?
> > > > >
> > > > > To use autopackage for Starez, you would need to create .package
> files
> > > > > of all your games you wanna distribute. We have lots of
> documentation
> > > > > and tools to assist you with this (
> > > > > http://www.autopackage.org/devel-zone.html is a
> good starting point).
> > > > >
> > > >
> > > > Okay, thank you.
> > > >
> > > > > I guess your "integration" could be done as some sort of "Starez
> Tool"
> > > > > that finds and downloads games from some central repository and then
> > > > > let the actual .package install itself.
> > > > >
> > > >
> > > > We're planning to ask game developers to publish on Starez. The game
> > > > developers should compile their own sources, package their own package
> > > > (maybe with a HOWTO or some help from a Starez packager), and then
> > > > deliver that on to us. We'll probably check the sources and scripts
> > > > there, to make sure no malicious content is spread to the clients.
> > > >
> > > > > Dependencies are handled by looking at the system directly. So if
> > > > > GameFoo needs Open GL, autopackage would check for the presens of
> > > > > libGL.so. If it needed gtk, autopackage would look for libgtk+.so
> and
> > > > > so on. The key here is that autopackage always examines the system
> > > > > directly, instead of going through some central database. This means
> > > > > dependencies can be installed by any package manager and autopackage
> > > > > will still find them.
> > > >
> > > > Yes. The idea was to make dependency scripts just check dependencies
> > > > and output what's missing and what's OK, and the client or installer
> > > > would just popup with what's missing. it won't interface at all with
> > > > any package managers, since that's just something we can't do, since
> > > > it's not portable between UNIX and Linux distributions *at all*.
> > > >
> > > > > Technically, dependencies are handled using skeleton files, which
> are
> > > > > shell scripts containing the logic for determining whether something
> > > > > is installed or not. More info about these are available here:
> > > > >   http://www.autopackage.org/skeletons.html
> > > >
> > > > We'll look into it.
> > > >
> > > > >
> > > > > > It might be an idea to get the .package file to print out an
> > > > > > indication of the installation progress every few seconds, and we
> read
> > > > > > that output from a pipe wrapped around the process, to update a
> > > > > > progress bar of some kind.
> > > > >
> > > > > If you want true integration, you can develop your own frontend to
> > > > > autopackage. The protocol is a simple string based one, and is
> > > > > described in both in plain text
> > > > >
> (http://trac.autopackage.org/browser/main/trunk/doc/PROTOCOL)
> and in
> > > > > three separate implementations (see gtkfe qtfe and ttyfe in svn),
> all
> > > > > under the GPL license. All communication is done over POSIX pipes.
> > > >
> > > > Okay, then this frontend will probably be the Starez installer. The
> > > > idea of a frontend and a backend talking over POSIX pipes was already
> > > > there, but not in the form of an autopackage backend, we'll surely
> > > > look into this.
> > > >
> > > > >
> > > > > I am not 100% sure that the PROTOCOL-doc is completely up-to-date,
> but
> > > > > it should give you a good overview at least.
> > > > >
> > > > > Of course, you don't *have* to do a frontend, if you are satisfied
> > > > > with the ones we provide already:
> > > > > * http://www.autopackage.org/gallery-gtkfe.html
> > > > > * http://www.autopackage.org/gallery-qtfe.html
> > > > > *
> http://www.autopackage.org/screenshots/newshots/ttyfe-install.png
> > > > >
> > > > > > I would love to hear your ideas around our problem, and whether
> it's
> > > > > > possible to use autopackage for Starez. Please be as clear as
> > > > > > possible, since we both have no experience with using autopackage
> > > > > > whatsoever.
> > > > >
> > > > > It should definitely be possible. I suggest you start simple, by
> > > > > packaging a few games as autopackages and then develop the
> supporting
> > > > > GUI tools and web sites (or whatever you have in mind) as a first
> > > > > step. You can then move on to develop a starez autopackage frontend
> if
> > > > > you think you need it.
> > > > >
> > > > > -Isak
> > > > >
> > > >
> > > > Thanks a great lot for your help. For myself, I'm really glad we got
> > > > such a helpful reply so we can make a carefully made decision.
> > > > Autopackage really sounds like the "thing we need". :)
> > > >
> > > > Sjors
> > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> autopackage-dev-unsubscribe-OfajU3CKLf1/[email protected]
> > > > > For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/[email protected]
> > > > >
> > > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> autopackage-dev-unsubscribe-OfajU3CKLf1/[email protected]
> > > > For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/[email protected]
> > > >
> > > >
> > >
> > >
> >
> >
>
>


-- 
Taj
http://www.wildgardenseed.com/Taj/blog

Need a GMail invite? Email me.
Peace cannot be kept by force; it
can only be achieved by understanding.
                -- A. Einstein

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/[email protected]
For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/[email protected]