On Wed, 28 Feb 2007 17:17:16 +0100, Ralf Corsepius wrote: > > > Well, the more I think about it, the more I am inclined to like the idea > > > to consider rpm's default behavior to override any modified file as a > > > bug. > > > > The bug is that somebody modifies installed non-config files without using > > the packaging system. > == You want users to package their customizations. Given the limitations > of rpm this means to rebuild the packages. Yes, the source rpms are available. Using local repositories is possible, too, and highly recommended if you want to install the same fix on multiple machines. > The point you seem to be missing is: I am talking about very few files, > admins might have customized, e.g. Customisation => %config files => done You refer to modifications which go beyond the scope of the software's configuration files. Else you would not need to touch non-config files. > * to work around bugs (I have stopped counting know how many times RH > has messed up my xorg.conf, my named.conf over all these years, Neither one is marked a %config file. Perhaps you refer to config tools which have written to the files [at install/update-time]? > and how > many times I have modified init-prios to work around this still unfixed > portmapper port allocation bugs) That doesn't require you to modify init files, though. > * to add missing/experimental features. > > * because they are developing on something. > > * because they have 3rd party packages installed which might apply a > different sub-package splits. This is an entirely different beast. We've come a long way to get confirmation, repeatedly, that 3rd party packages either are compatible or aren't. > * because traditional packaging of packages were designed to be modified > (e.g. site-wide app-defaults) In non-%config files? > > Admins, who do that, often > > forget what files they've changed, and "rpm -Va" only reports the changed > > checksum, not a diff. > > Please, try that. With Fedora, the results of an rpm -Va is hardly > usable (alternatives, files outside of rpm control, missing dir > ownerships etc.). Even more reason to install modifications via RPM packages. > > And what behaviour would you prefer during a dist-upgrade? That RPM > > refuses to install new binaries, because the user has replaced them with > > modified files? > Nope, I'd prefer an rpm that refuses to replace modified _files_ (Note: > files, not packages) and backs them up (similar to *.rpmsave or > *.rpmnew). Of cause such an rpm also would have to have a "--force" mode > to forcibly replace such files. *.rpmnew for such files would be a show-stopper. Just imagine how RPM could not guarantee integrity of an installed set of packages, if it installed any updated files as *.rpmnew. I can think of RPM creating backups of any files, which don't belong into any package, before overwriting them. But the problem is selfmade: modifying files which belong into packages, and mixing unpackaged files and packages in an installation. This bears the risk of breaking in many places. It's also one reason why the filesys has places like /usr/local and site-specific install locations. -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
