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. 
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 systemI 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.
»|« Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.