On Apr 20, 2013, at 6:02 PM, Phil Pennock <lopsa-t...@spodhuis.org> wrote: > > If your package management system insists on owning all files in /etc/ > and complaining if you choose to change the state of some them by > rolling back a change, then your package management system is broken. > > It's acceptable for package management to create new files in /etc/ on > first install but if it wants to own the ongoing state then it's flawed.
Hear, hear! It would make sense for packaging and package managers to evolve to the state where: - The config is in a separate, "configuration file only" package, just as there are "dev only"/"client only"/"server only"/"documentation only" packages today. - Generating new, per-machine or per-use-case config packages is extremely easy to do (imagine having a "<packagemanager_name> capture" command that generates a new package with current on-disk changes to files managed by that package) - These packages can be integrated on system build when deploying - The package managers file integrity checks would always pass on even a fully customized system Unfortunately, the state of packaging appears to be frozen in time, and we're still binding compiled code and the config "state" for that code in ways that most programmers recognized as being flawed and undesirable decades ago. - Zack -- Zack Williams - Artisan Computer Services - 520.867.8701 z...@artisancomputer.com http://www.artisancomputer.com ACSA, MCP SBS, SCSA, LPIC-1 _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
