On Tue, 2005-06-14 at 13:40 -0400, Matthew Miller wrote: > On Tue, Jun 14, 2005 at 10:14:25AM -0700, Florin Andrei wrote: > > After all (I apologize for repeating it over and over again, but I think > > it's a crucial point), whatever the situation before the upgrade, it was > > very likely the result of a decision made and an action carried by the > > human operator. The software should not treat it lightly. > > I disagree. This is *exactly* the same case as if the user has done > > rm -f /bin/ls > > When you upgrade coreutils, it'll fix this by putting /bin/ls back. Oh, come on, how could that be similar? The example is so wrong, I'm not even sure how to approach it. /bin/ls is part of the coreutils package as a fixed, unchangeable component. "Fixed" with regard to sysadmin's actions. You're not supposed to mangle /bin/ls or similar parts of the package, you are supposed to let RPM deal with that. I.e., don't blindly do a "make; make install" in the coreutils source tree if you have an idea of how to improve the /bin/ls executable, but you're supposed to create a package and do an update "properly". The symlinks in /etc/rc*.d however, those are a different story. You are allowed to make changes. They're similar to config files. The user should normally not make changes to the binary files, executables, libraries, etc. and, if changes are made, the package manager is entitled to fix them, as you correctly point out. However, runlevel symlinks, config files, etc. are supposed to be subject to changes by the user/sysadmin. The package manager should not overrule those changes. Case in point, often the config files are left unchaged after a package upgrade, in order to preserve whatever modifications were made by the user. /etc/rc*.d symlinks are the same, since their state is often the result of actions taken by the sysadmin. To let RPM overrule the sysadmin's decisions w.r.t. those symlinks is like letting RPM blindly overwrite config files during "rpm -U" and not save backups of the old files. -- Florin Andrei http://florin.myip.org/ -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-devel-list
