Bugzilla Bug 59920

Hello.  I just released version 1.6.6 of Deadly Rooms Of Death for Linux (in
portage under the name drod).  I'm actually a gentoo user myself, but I didn't
make an updated ebuild because some of the things you do in the 1.6.5 ebuild
puzzles me somewhat (see below for more about that).

This version should solve gentoo bug #42836, among other things (the installer
checks for existing files in the *real* target directory and skips copying
existing files to the temporary (sandbox) directory if overwrite is set to no. 
I hope this will work with the portage sandbox.)

This version also has the new feature that if DROD detects any data to be
read-only when run, all data is copied to the current user's home directory,
under $HOME/.caravel/drod-1_6 (btw, DataPath.txt was moved to this directory as
well, but you shouldn't have to worry about that).  In other words, when
installing the dat files read-only, each user that runs DROD will get their own
copy of the data.

Now, I've got a few comments about the current ebuild (1.6.5), which does some
strange things (I guess this is partly my fault for not actually documenting
the installer options except in the installer itself...)

First of all, you patch the installer, when there's no need to do that for what
you want it to do.  You can just use the command-line options!  You already use
some of them, so you must have known they were there, and I'm not sure why you
do it this way...  In any case, run the installer with the -- --help option for
a list of all options.

Second, you install the data into /opt/drod/bin/Data, and the resources into
/opt/drod/bin...  Um, why ?  It would be better to just use -s /opt/drod to
place the binary in /opt/drod, the data and resources in /opt/drod/Data,
libraries in /opt/drod/Libs, etc (that's what the option was made for,
actually).  I guess the install structure has to stay your way now, though, so
people that already installed DROD can keep using their old dat files.  Oh
well, it's not the end of the world =)

Third, you depend on all the libraries that's actually included in the
installer.  Running the installer with the -rl (copy required (missing) libs)
or the -al (copy all libs) will put everything DROD needs in a little directory
by itself, so you actually don't have to depend on anything.  Using the -rl
option will make DROD use the system-wide copies of libraries it can find while
using its own copies for the missing ones, so there's no need to depend on
anything.  I guess it's a matter of preference whether someone would like to
have everything system-wide (and customized), though.

These three points may just be how you actually *wanted* things to be.  In that
case, feel free to ignore me.  It's your distro, after all =) .  Also, if
anyone have any questions, comments, etc, you can either reply here or send an
email to gerryj (at) caravelgames (dot) net.

Thanks =)

Reproducible: Always
Steps to Reproduce:

i cant comment on why the installer works the way it does (mr bones wrote it
originally i think), but we can touch up the ebuild to handle updating the data
files correctly

we'd prefer to use bundled libraries when dealing with binary packages since
it's  lot less of a headache

could you post a final installer command that'll cover everything you've
mentioned here ?

Sure!  There's a few choices, but take this one, for example (there's a problem
with this command when 1.6.5 or earlier is installed, though, see below):

./CDROD-1.6.6-setup.sh.bin -- -R /path/to/sandbox -s /opt/drod -al -pg -no -I

If portage already decompressed the makeself archive, and you're in the
uncompressed directory, replace "./CDROD-1.6.6-setup.sh.bin" by "./install.sh",
and skip the double dash:

./install.sh -R /fake/root -s /opt/drod -al -pg -no -I

Replace the argument to -R (/fake/root) with the path to the sandbox, of
course.  -s selects "single" (opt-style) installation, putting the binary in
/opt/drod, data and resources in /opt/drod/Data, libraries in /opt/drod/Libs
and a symlink to the help files in /opt/drod/Help.  -al selects to install all
libraries.  -pg specifies that data should be writable by the "games" group (ie
all users in the games group use the same data).  -no means no overwrite, and
-I starts the install without any questions.

If you prefer that each user should get own copies of the data in their home
directory (under ~/.caravel/drod-1_6) when running DROD, replace the -pg option
by -pn (stands for permissions noone; data won't be writable by anyone, so
they'll always get copied to a writable location (the home subdir I mentioned
above) if required).  Note that the -p? options doesn't change permissions of
existing files, only new ones.  Maybe you could have a use flag or something so
people can select what they want.

The current ebuild uses -pg.  That's more space efficient, since the dat files
can grow large when you install other holds, build your own, save demos, and
the like.  DROD handles multiple users fine, so that's not a problem (although
everyone with access to the data can select and play with any other player
stored in those datafiles, so there may be some privacy issues...)

Anyway, the problem I mentioned above is that since the data is copied to a new
location (/opt/drod/Data in stead of the old /opt/drod/bin/Data), and because
DataPath.txt (a file that remembers the location of data and resources) has
moved, the old datafiles won't be found.  Also, since the installer doesn't
find any existing data in /opt/drod/Data, new data files will be installed,
making it look like you lost everything.

To fix this, you could make the ebuild check if there's any files in
/opt/drod/bin/Data, and if so, move it all to /opt/drod/Data either before
install or after installation is complete (and remove the old dir afterwards). 
Important:  Do this in the *real* filesystem.  The installer only check for
existing files in the real target location (ie the fake root option (-R) is
ignored for the file-exists check), and any sandboxed data will overwrite the
existing files when portage moves them.

If this sounds like too much work, you can just keep the old install locations:

./CDROD-1.6.6-setup.sh.bin -- -R /fake/root -b /opt/drod/bin -l /opt/drod/lib
-r /opt/drod/bin -d /opt/drod/bin/Data -D /opt/drod/doc -al -pg -no -I

(or "./install.sh" in stead of "./CDROD-1.6.6-setup.sh.bin --", like above)

This will detect existing data as they're installed in the current ebuild
setup, and not copy any new data if existing ones are found.  Again, you can
change -pg to -pn if you want (see above).

Btw, since we're using -al, you can change the ebuild to have no dependencies.

Have fun ;) , and let me know if there's anything else you want to know.

- Gerry

Created an attachment (id=38558) [details]
drod-bin-1.6.6.ebuild

i think this ebuild should de everything you want and everything we want :)

please give it a quick eye over and i can get it into portage, sorry for the
delay

I had a quick look, and found two problems:

First, it seems to create a symlink to /opt/drod/bin/drod, although since you use the -s option of the installer the drod script is placed directly in /opt/drod.  So, I think you have to change "dosym ${GDIR}/bin/drod ${GAMES_BINDIR}/drod" to "dosym ${GDIR}/drod ${GAMES_BINDIR}/drod"

Second, you only make a backup copy of the old data if it's present, and don't overwrite the new data.  There's nothing wrong with that, except since you decided to use the -pn option the data in /opt/drod/Data will only be used the first time DROD is run by a user, to copy the datafiles to the home directory and make them writable there.  So, if someone upgrades DROD to 1.6.6, runs the game, notice that the saves are gone, find the backups, and then overwrite the data in /opt/drod/Data with those, the saves will still be gone since the data in /opt/drod/Data isn't used after the first run.  Also, any other users that run DROD for the first time after this *will* get the saves from the backup.

Anyway, you don't need to change the behavior of the ebuild for this, but you should probably add a note that says the data in /opt/drod/Data is only used the first time DROD is run by a user, to make writable copies in ~/.caravel/drod-1_6.  Any later runs by that user will use his/her local data files.  So, to restore the backup data, the user will either have to overwrite the data in ~/.caravel/drod-1_6 (probably the best way, but make sure they're owned by the user afterwards), or simply delete the ~/.caravel/drod-1_6 dir and overwrite the global data in /opt/drod/Data, although that will make the saves available to anyone else who runs DROD later (also, if they do this they should make sure that the permissions are okay after the overwrite -- if the dats are writable by any user that runs DROD, those files will be used directly, and local copies won't be made).

The rest of the ebuild looks fine, though =)

Btw, I think the best way to restore the backup data for a single user would
be:

* Upgrade to DROD 1.6.6 =)
* Run drod once, exit (to create ~/.caravel/drod-1_6/DataPath.txt)
* Overwrite the data in ~/.caravel/drod-1_6 with the backups, make sure they're
owned by the user.

It's been a month since my last comment here.  Because of the rather serious
export bug in 1.6.5, it would be nice if this was updated soon...  So, if
there's a reason why this isn't in portage yet, please let me know.  I can
probably help.

Honestly, the reason is probably because there is only 3 developers on the
games team and we all perform other duties in Gentoo besides games.  Are you
saying that the older version of the package currently in portage has a
possible security flaw?  That would definitely increase the priority of
updating this package.

Unfortunately, I cannot comment on why the 1.6.5 ebuild was done the way that
it was because I am totally unfamiliar with the package.  Perhaps if one of the
other devs doesn't get on this shortly, I'll see what I can do.  The main this
is just to have a little patience.  Right now my backlog of bugs is quite a bit
longer than a month.

Well, there was some possible security flaws fixed, of the off-by-one type (and
one unterminated string in the data searcher), but I don't think there is a
high risk of those being exploited.  Also, since the data is writable by all
users in the games group in 1.6.5, there's some possible security issues there
as well, I guess (since any player can play/edit/delete any other player).  The
1.6.6 ebuild defaults to installing read-only data, which DROD 1.6.6 will
detect, and create local user-writable copies in the user's home directory on
the first run.

Anyway, the export bug I mentioned is just a major inconvenience for the
players, in that all exported files are corrupted.  In other words, they can't
save their progress in an external file (for backups, importing at other
machines, etc), and also can't export custom "holds" (= dungeons, level
collections) they've created to share with the DROD community.

Bump.  This update request is now 8 months old.

If we had a working ebuild it would help move things along.  The one attached
doesn't cut it.

Version bumped in CVS.  Old ebuilds removed.