Re: Intergrating autopackage in Starez

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).

> 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).

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.

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.

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

> 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.

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

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