Re: Intergrating autopackage in Starez

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]