A couple patches, etc

Gerry JJ trick at icculus.org
Sun May 25 13:53:00 EDT 2008


Hello there.  Made some new DROD installers recently, which brought up a
few issues.  I've attached a .patch file (against svn head, rev 563)
that fixes some of them.  All of these patches are in the latest DROD
v3.2.0.83 installers and seems to work =).  Some comments:

1. scripts/mojosetup_mainline.lua, @@ -1328,6 +1328,7 @@:
The installer would fail if attempting to install into a directory
whose parent directories didn't yet exist.  This fixes that by making
the parent dirs first if required.

2. gui_gtkplus2.c, @@ -171,8 +171,8 @@:
Destination browse button: Set initial path to the path currently
selected in the combo box.  (GTK will pop up a dialog to complain if the
currently selected path doesn't exist, but imo that's ok; it alerts the
user that the path isn't what it might be expected to be and then sets
the directory to the first valid parent dir in stead, which is excatly
what the FIXME there suggests to do).

3. docs.txt, @@ -297,7 +297,7 @@:
Typo: postinstall -> postuninstall

4. gui_gtkplus2.c, @@ -754,7 +754,7 @@:
The entries in the destination combo box was in the reverse order, this
patch fixes this, ie the first path in recommended_destinations array
appears first in the list (also consistent with ncurses ui).

5. platform_unix.c, @@ -508,7 +508,7 @@:
This is in the MojoPlatform_unlink function.  We need to use lstat here
in stead of stat, since stat will fail if the target is a dangling
symlink.  lstat handles that, and works fine for other files too.

6. platform_unix.c, @@ -1170,11 +1170,18 @@:
In MojoPlatform_switchBin.  Switching binaries very occasionally failed
for no apparent reason (easy for me to detect since 32-bit and 64-bit
gtk looks different on my dev box).  The reason appears to be that the
directory entry for the new executable wasn't updated before mojosetup
launched it.  This patch tries to avoid that by first fsyncing the fd
before close and then waiting a little bit if the chmod fails and try
that again a few times.  (There's probably a better way to do this.  I
first tried to do fsync on the dir, but that didn't really work out.
Also, this might be required for the gui plugins too, though I didn't
have problems with those).

7. lua_glue.c, @@ -1121,7 +1121,8 @@:
This adds autodetection for splash orientation (while we're waiting for
a splash position setting in the config =)).  Splash images that are
wider than they are high (or square) goes on top as before, images that
are higher than they are wide goes on the left.  The new DROD installers
rely on this, so I hope this will get approved =)

Some other isses and feature requests I didn't find/patch yet (since I
found ways around them and was in a bit of a hurry):

* Setting permissions through the file filter by returning name, mode
 doesn't seem to work anymore?  At least it had no effect at all on
 permissions on my test runs, both from regular directory and appended
 zip archive.

* The uninstaller returns true if aborted.  (I'd expect it to return
 false in all cases where the installed app wasn't uninstalled.)

* Is generic name for desktop menu items really required?  I ran into a
 bug in KDE (I think) where it'll sometimes mess up the names and
 display only the generic name if the main name includes a colon.  (I
 got around this by setting both name and generic name to be the same)

* A hook for running things after the main eula has been accepted but
 before install options are selected would be nice.  (The DROD
 installers detects existing installations and prompts to uninstall
 the previous version before going on with the install.  Currently this
 is done in precheck, but I think doing it after the eula, yet before
 options, would be more natural.  preflight is run after options.)

* A yes/no/cancel dialog would be nice.  (For example, for the
 uninstall prompt, the choices could be yes for uninstall, no for
 don't uninstall but continue installation, or cancel for abort
 install.)

* Also, is there a way to signal that the installation should
 not continue without popping up an additional dialog box (through
 fatal) for people to click through?  (For use in abort install
 questions)

* A way to get the home dir for root, if possible.  When running an
 installer through sudo, the home directory is not updated.  This
 became a problem for me because I put a symlink to the manifest xml
 in $HOME/.caravel/installed/<id>.xml (to detect existing installations,
 and for compatibility with some earlier versions which used Loki
 Setup), but doing this under sudo will put files owned by root in the
 user's home directory (and location depends on current user,
 obviously, so detection might fail if run by a different user).
 Currently I just detect euid and see if '/root' exists and use that
 for home in stead if it does, but I'm not exactly thrilled with that
 solution..  (You could also argue if /root is the right place to put
 that in the first place, but it's what Loki Setup did.  Bah.)

* It'd be nice if MojoSetup supported installation of (semi-)globally
 shared, writable data.  Actually this is related to a feature request
 I've got for PhysicsFS; have two different write paths at once, one
 for user-local and one for shared data.  You can't simply use
 PHYSFS_setWritePath for this since PHYSFS_setWritePath will fail if
 some files are still open in the old write path, and there's also no
 cross-platform way in physfs to get the shared path (would maybe use
 CSIDL_LOCAL_APPDATA in Windows and probably /var/games/<id> in Linux,
 at least for games?).  Anyway, what I'm getting at here is that this
 directory also needs to be set up with right permissions (also system
 dependent), which is probably best done by an installer.  Like
 MojoSetup, say.

- Gerry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mojopatch.patch
Type: text/x-patch
Size: 3885 bytes
Desc: not available
URL: <http://icculus.org/pipermail/mojosetup/attachments/20080525/594bbfe3/attachment.bin>


More information about the mojosetup mailing list