bad practice: not reading the manpage

Florin Andrei florin at andrei.myip.org
Tue Jun 14 18:00:57 UTC 2005


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/




More information about the devel mailing list