[Kde-games-devel] Releasing and installing data files

[Ian Wadham]

Re distribution of KGoldrunner game levels, these are (imho) a
special case of a more general requirement which will increasingly
arise in KDE apps, if it does not do so already (more below).

----- Original Message ----- 
From: "Rob Kaper" <cap at capsi.com>
> I'm still not fond of distributing the levels in one tar, that's not
really
> how KDE usually handles its installation.. it should be possible to do so
> more nicely without requiring manual editing for every new level added.
>
For new readers, KGoldrunner has about 200 levels files.  To avoid the
administrative overhead and risk of errors and omissions in Makefile.am
and CVS, I have packed the files into a single "levels.tar" file, with an
extra "install:" step in the Makefile.am to untar the files.  Unfortunately,
KDE (and [all?] other Linux applications) get installed by "root" and
"tar xf" will not change file access and ownerships if you are running as
"root", so KDE CVS Admin have added a "chown root.root ...", but
that fails if you are _not_ running as "root".

The only solutions I can think of are:

1. Change all the file ownerships to "root" before I "tar" the files.  That
    assumes that "root" is user ID zero, group ID zero on all Linux
    machines, as it usually is in UNIX.

2. Re-write KGoldruner to put all levels in one file.  Not a good idea.
    That would go deep into KGr structure, at the risk of introducing
    some nasty bugs ... besides being _more_ work for me ... :-(

3. Long term, KDE could install as user "kde" and group "kdeadmin".
    Maybe there should be a "kdegames" owner, too.  Maybe special
    owners for certain applications, such as Database Management
    Software (DBMS), as there is on UNIX machines.

Alternative 3 is obviously not viable right now.  For one thing, you'd
have to get SuSE, etc. to create more users than "root" and the machine
owner when they install Linux.

What is the point of 3?  Well, having 75% of all the files owned by
"root" can be harmful to the software and to the machine's owner.  He
or she may be tempted to do "su" and start hacking at stuff, without
being aware of the ramifications, then might unintentionally damage
real "root" stuff and cause the system not to work any more.

At my last UNIX site, we had special users "ingres" and "dba"
(Database Administrator).  DBA's could log in as "dba" and do
special stuff to databases, such as running recovery or creating
indexes, but could not harm the INGRES or UNIX software and
did not require any in-depth knowledge of UNIX (such as the "root"
users had).  DBA's could also log on as "ingres", but only to do
stuff like patch the INGRES software.  Conversely, although they
had "super" powers, "root" users could easily recognise files
owned by "dba" and "ingres" and treat them with care.

KDE and Linux will need measures like that, to segregate
responsibility, as they get bigger and more complex.  Otherwise
they will wind up with security not much more sophisticated
than Windows has.

Another aspect is the question of how to distribute data files, as
opposed to code.  Applications will increasingly come out that
have associated data files, such as demos, libraries of pictures,
fonts, template databases ... and levels in games.

There should be some easier way to compose and distribute
new data files (e.g. new levels for a game) than by going through
the full development and release cycle, with automake, autoconf,
CVS, and all the knowledge they entail.  If I am a photographer
and I have some nice pictures to add to the photo-processor
package's libraries, I should be able to do so with almost
zero technical knowledge of KDE and Linux.

Something to think about, Ian W.