On Thu, 2006-04-13 at 21:38 -0700, Jane Dogalt wrote: > This is a great idea and something I was planning on doing myself. But for > simplicity, it seems like this could be implemented dirt-simply (from an > infrastructure impact point of view) via rpms. I.e. rpms that are heavy on > specifying dependencies and pre/post scripts, but probably very light on files > (if not in fact lacking any rpm owned files). While it's very tempting to do that, and I've seen quite a few places that try to manage their config this way, pre/post scripts are a very poor way to define the configuration of a machine: they leave no trace of what they did, scripts by their very nature are entirely operational (how would you display what the scripts do in a UI ?), they introduce very tight coupling between dependent packages, and they give you no help in figuring out if a machine's configuration deviates from what was initially installed (think about finding out that somebody has edited /etc/passwd and changed httpd's login shell to /bin/bash). In addition, building rpm's to roll out config changes is a fairly heavy-weight process - do you really want to rebuild an rpm just to fix a typo in a config file somewhere ? > Hopefully you write the rpm uninstall > scripts with enough intelligence to revert the system exactly back to the > preinstall state. That's another problem with pre/post install scripts: all that intelligence needs to be handcrafted for each script. And when things go wrong, it's very hard to figure out what went wrong and why. Config mgmt tools seem a much better solution for these kind of things than rpm's. David -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
