Splitting defaults from user configs

This is a suggestion, or feature request.

One of the things I always find annoying about upgrading RT is
checking config.pm for changes. If config.pm moved to somewhere in
lib, and become config.defaults.pm. Users would edit a separate
config.pm that would override the defaults, and start off being
empty. sort of like the bsd rc.conf system

seph

seph wrote:

One of the things I always find annoying about upgrading RT is
checking config.pm for changes. If config.pm moved to somewhere in
lib, and become config.defaults.pm. Users would edit a separate
config.pm that would override the defaults, and start off being
empty. sort of like the bsd rc.conf system

I like.

“make upgrade” should also diff the old and new configs for the
user, so if there’s any config.pm changes that might be needed,
they’re obvious.

(Incidentally, seph, consider keeping your RT sources under
CVS control (or similar). You’ll soon forget about the config.pm
update dance. :slight_smile:
Phil Homewood, Systems Janitor, www.SnapGear.com
pdh@snapgear.com Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - Custom Embedded Solutions and Security Appliances

seph wrote:

One of the things I always find annoying about upgrading RT is
checking config.pm for changes. If config.pm moved to somewhere in
lib, and become config.defaults.pm. Users would edit a separate
config.pm that would override the defaults, and start off being
empty. sort of like the bsd rc.conf system

I like.

So yeah, I was pondering somthing like this (since we’re now doing
something similar for libraries.) Though ideally, it’ll be three-tiered:
System, Vendor and User.

»|« http://www.bestpractical.com/rt – Trouble Ticketing. Free.