Re: Redhat upgrade problem - packages fail rpm -Va
From: Dave (shuvit_at_127.0.0.1)
Date: 10/11/03
- Next message: Peter T. Breuer: "Re: redhat server"
- Previous message: Dan DeVincent: "Re: Recommend Linux Distro, Mail/MTA/FTP daemon?"
- Maybe in reply to: Dave: "Redhat upgrade problem - packages fail rpm -Va"
- Next in thread: Bill Unruh: "Re: Redhat upgrade problem - packages fail rpm -Va"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 11 Oct 2003 11:57:14 -0700
"Robert M. Riches Jr" <spamtrap42@verizon.net> wrote in message
news:slrnboer2m.mof.rob@one.localnet...
[...]
> Some differences are likely due to customization options
> done during installation.
These are generally marked with a 'c' in the output of 'rpm -Va'.
Configuration files like this are allowed to change, and maintaining these
changes through the upgrade process is what a good upgrade command should
do.
> Some may be due to the same file
> being owned by multiple packages, where the packages
> disagree on mode/permission bits or something similar.
This should not be the case with a "standard" set of packages. The
distributor should decide which is the correct final state of the shared
file and make that the specified state for verification. If it were an
*added* package, then I could see a challenge. The ideal installer should
warn that a shared file is about to be replaced, show which packages claim
"ownership" of the file, and offer an option to leave the file as is.
> It is my belief that at least some others are due to mistakes
> in the descriptions in the RPM packages--the
> mode/permissions of /dev/shm, for example.
I'm seeing that also. The 'dev' package alone accounts for 215 of my
current 312 errors. /dev/shm has an error code M. Most of the others are
showing U and G errors.
I'm seeing some other discrepancies also - files that are modified *after*
the install, but are not config files.
The package 'up2date' is a good example.
[root@saguaro redhat]# rpm -Uvh --replacepkgs up2date-3.1.23.2-1.i386.rpm
Preparing... ###########################################
[100%]
1:up2date ###########################################
[100%]
[root@saguaro redhat]# rpm -V up2date
SM5....T c /etc/sysconfig/rhn/up2date
S.5....T c /etc/sysconfig/rhn/up2date-uuid
{Only config files in verify error list. Good so far.}
[root@saguaro redhat]# cd /usr/share/rhn/up2date_client
[root@saguaro up2date_client]# ll | grep up2dateUtils
-rwxr-xr-x 1 root root 4980 Aug 28 19:36 up2dateUtils.py
-rwxr-xr-x 1 root root 7484 Aug 28 19:35 up2dateUtils.pyc
... {Notice the dates of these freshly installed files.}
[root@saguaro redhat]# up2date
{Your system is fully updated. No new packages are needed.}
[root@saguaro redhat]# rpm -V up2date
SM5....T c /etc/sysconfig/rhn/up2date
S.5....T c /etc/sysconfig/rhn/up2date-uuid
SM5....T /usr/share/rhn/up2date_client/up2dateUtils.pyc
{Notice the extra error - not a config file.}
[root@saguaro redhat]# cd /usr/share/rhn/up2date_client
[root@saguaro up2date_client]# ll | grep up2dateUtils
-rwxr-xr-x 1 root root 4980 Aug 28 19:36 up2dateUtils.py
-rw-r--r-- 1 root root 8053 Oct 11 11:04 up2dateUtils.pyc
{Notice the changed date.}
There are a lot these '.pyc' python object files in the distribution. I
don't know why it should ever be necessary to change a program file that is
not a config file, but assuming there is some good reason for this, we may
need some improvements in rpm to maintain the integrity of the verify
process. The fix I'm thinking of would require adding a new category of
file to the "config" files that rpm already recognizes. We could call these
"generated" files, and flag them with a "g" so they could be excluded from
our error lists. These files are expected to change frequently and
automatically, but unlike config files, they are generated automatically
without any user input. We can think of them as temporary files.
> Once you get a good, clean install with a small number of
> initial mismatches, keep around a running copy of what 'rpm
> -Va' returns. Compare before-and-after each significant
> change in installed RPM packages. That way, if something
> goes wrong long after installation, you can find out earlier
> rather than later.
This is my plan ( if I stay with Redhat.)
I'm really looking for a system that I can "lock down" the critical files,
and not worry too much about adding things over time, and not have to ever
repeat a configuration once I have painfully worked out the details. I have
tried to keep notes on these configurations, and it never works. No matter
how careful I am, I can't follow my notes the next time around. If I were a
system administrator, I would learn this stuff. As a user, I expect
upgrades to go a lot more smoothly.
In spite of the possible limitation of not recognizing "generated" files,
discussed above, I still think the problems I've encountered these last few
days are not inherent in rpm. rpm seems like a robust and well-designed
package managment system. I think the fault lies with the package builders
and the distributor. They have failed to get things organized properly so
non-expert users can do an upgrade. The machinery is all there. They just
need to focus more effort on the individual user, and not expect everyone to
be part of some "enterprise" account where the experts take care of all
setups.
We can lean something from Microsoft's install process. Not that we should
duplicate all the bizarre "registry" crap, but we should expect to get the
same level of "installability" in Linux packages. When I install or
uninstall a package in Windows, it almost always goes smoothly. The upgrade
from W2K to XP was a breeze.
-- Dave
- Next message: Peter T. Breuer: "Re: redhat server"
- Previous message: Dan DeVincent: "Re: Recommend Linux Distro, Mail/MTA/FTP daemon?"
- Maybe in reply to: Dave: "Redhat upgrade problem - packages fail rpm -Va"
- Next in thread: Bill Unruh: "Re: Redhat upgrade problem - packages fail rpm -Va"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
