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