If you can't get around it by not starting anything (by default) on AC power (that is, using, hijack to launch "occasional use" things), I'd recomend just commenting out the offending ;@EXECs and rebooting before syncing.


Messy - manual commenting out on every sync is going to be as (if not more) painful than reconfiguring apps after an occasional upgrade. Automagically commenting them out is going to require careful coding in JEmplode to ensure that it handles already commented out EXEC lines correctly afterwards.

And it would be a delaying factor anyway - we'd need to reboot after disabling apps, which would then need JEmplode to re-read the database.

To do this right, we need to have a cohesive strategy that utilises JEmplode, hijack and on-player utilities when appropriate.

I'd suggest that the specs for this strategy should include as a base. I apologize in advance for being presumptious about changes needed to other peoples' work.

1) Initial setup (from a hijacked but otherwise 'vanilla' Official release) should be a one button click operation in JEmplode. (I'll accept 2 buttons if you count 'Sync' )
1.1) This setup should be repeatable without loss of any existing data after an official upgrade.
1.2) The setup should include on the empeg any binaries or shell scripts that JEmplode needs to manipulate and install packages.

2) The strategy should allow for (non-application related) syncs to occur from the Empeg-offical Emplode;
2.1) without any modification of config.ini
2.2) without any changes to Emplode itself
2.3) without adding any reboots.

I think that if we can get those first specs well understood, and a strategy to implement them, then it makes the other specs much easier to implement;

3) Suitable package system facilitating;
3.1) Point and click application install.
3.2) Point and click application upgrades, including intelligent handling of application config files.
3.3) Removal of packages... (allow config files to remain? Make that optional?)
3.4) config.ini EXEC lines. (e.g, provide a list of selectable options)
3.5) Package must include a simple method of versioning that JEmplode can read.

4) JEmplode should interact with the package and associated on-empeg utilities to perform the install, configuration or uninstall.
4.1) Should be capable of locating the package on the local filesystem.
4.2) Should be able to parse the package for version and configuration information.
4.3) Should be able to present user with selectable config.ini options based upon package recommendations. User should be able to define their own selection if desired.
4.4) JEmplode should be capable of (optionally?) displaying installed apps, and associated config files in the tree.
4.5) Should interact with the on-empeg utilities to install, (intelligently) upgrade or remove packages, including config.ini changes.
4.6) Should be able to temporarily disable application (through config.ini change) without removing it.


As I said, I think that this needs to be a 3 pronged approach to be really successful - and will require co-operation between efforts would be required.