Hi!
0.2-beta is a great upgrade. While leafing through the new config
options available in main.inc.php, it occurred to me that the upgrade
process could be simpler yet. If I can avoid making changes to the
shipped main.inc.php, then when upgrading I can always replace it with
the new version as shipped (taking care to see what's new, of course).
This is easy, if the shipped main.inc.php ends like so:
--- /usr/pkg/share/examples/roundcube/main.inc.php.dist 2008-09-21
23:24:14.000000000 -0400
+++ /etc/roundcube/main.inc.php 2008-09-24 15:00:31.000000000 -0400
@@ -377,5 +377,7 @@
// Display attached images below the message body
$rcmail_config['inline_images'] = TRUE;
+include_once('main-local.inc.php');
- // end of config file ?>
Then, if the sysadmin creates main-local.inc.php, any settings it
contains will override the defaults, and main.inc.php can be treated
as read-only if the sysadmin so desires. And for some uses, at least,
that makes it easier to compare the old and new main.inc.php to see
which new settings are available.
(Same idea applies to db.inc.php.)
I can't say I've noticed any sort of performance hit as a result of
this, and I'd be surprised if there were much of one, but my
environment isn't terribly high-load and I haven't profiled anything.
With this change, working in the way I'm talking about is entirely
optional; nobody has to change how they do things unless they want to.
Would this change be acceptable in RoundCube?
- Amitai
List info: http://lists.roundcube.net/dev/
Amitai Schlair wrote:
+include_once('main-local.inc.php');
I can't say I've noticed any sort of performance hit as a result of
this, and I'd be surprised if there were much of one, but my
environment isn't terribly high-load and I haven't profiled anything.With this change, working in the way I'm talking about is entirely
optional; nobody has to change how they do things unless they want to.
Would this change be acceptable in RoundCube?
Not bad, but I think that planned upgrade script should handle config differences.
On 25 Sep, 2008, at 2:28 AM, A.L.E.C wrote:
Amitai Schlair wrote:
+include_once('main-local.inc.php');
I can't say I've noticed any sort of performance hit as a result of this, and I'd be surprised if there were much of one, but my environment isn't terribly high-load and I haven't profiled anything.
With this change, working in the way I'm talking about is entirely optional; nobody has to change how they do things unless they want
to. Would this change be acceptable in RoundCube?Not bad, but I think that planned upgrade script should handle config differences.
Where can I read more about how this script might work? A quick search
of the trac didn't get me there.
My motivation here, as a packager, is to take advantage of automated
config-file handling present in some package systems. For instance,
I'm working with pkgsrc, which already handles config files fairly
intelligently. At install time, a pristine copy goes into share/
examples/roundcube, then copied to /etc/roundcube unless a file by
that name is already there; at uninstall time, if the file in /etc/
roundcube compares equal to the original, it's removed, else left
behind for the sysadmin to deal with (and a notification printed). So
if pkgsrc's RoundCube package can provide sysadmins with the option of
not modifying /etc/roundcube/main.inc.php, then life across upgrades
can become quite simple for those sysadmins.
The upgrade script would certainly be useful for other cases (package
systems without this feature, users installing RoundCube manually),
but for the problem I'm trying to solve, I'd like to see my idea
implemented also -- especially as it's so trivial. :-)
Thanks,
- Amitai
List info: http://lists.roundcube.net/dev/
-
A.L.E.C -
Amitai Schlair