On Wed, 2007-02-28 at 18:12 +0100, Michael Schwendt wrote: > 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. Inapplicable to "joe average" > Using local repositories is possible, > too, and highly recommended if you want to install the same fix on > multiple machines. How do you think did I get into packaging? Because it's fun? No. Because the limitations of rpm, how it had been used by vendors (% config) and vendors not having been able to provide bug-fixes in reasonable time had forced me into it. > > 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 Yes! But this thread started with the FPC having decided to drop %config on init scripts, because the majority of FPC members doesn't consider them to be config scripts. i.e. this decision has rendered this way of bug-fixing impossible. > You refer to modifications which go beyond the scope of the software's > configuration files. As I said many times before: init scripts traditionally have been config files, ever since *nix'ish OSes exist (the origin is the early *nixes having used monolytic rc.local init scripts). > > * 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]? True, xorg.conf isn't owned by any rpm, and named.conf seems to be ghosted, but ... if not them which files else are config files? > > * 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. At the very moment a package is being introduced into Fedora, any existing 3rd party package has no chance to be compatible > > * because traditional packaging of packages were designed to be modified > > (e.g. site-wide app-defaults) > > In non-%config files? Init scripts was the point this thread has started with. Now people have started a crusade against %config files outside of /etc. > > > 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. Again matter of POV: It's often the easiest way to fix (often trivial) bugs, and it's often the easiest way to add features. > 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. This doesn't help when it comes to packaging bugs below /etc, esp. to bugs in init scripts. Just imagine an initscript having a typo in a rarely used "case/switch". The quick fix would be "fix that typo". Without %config, the next update will blow this change away. If Fedora hasn't fixed it, ... your changes will be lost. Ralf -- 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
