On Wed, Jan 17, 2001 at 04:21:19PM -0600, Jason L Tibbitts III wrote:
> >>>>> "PS" == Pekka Savola <[EMAIL PROTECTED]> writes:
>
> PS> I haven't done this myself, but wrapping up some magic that'd fetch all
> PS> the headers and check for Obsoletes: field might work.
>
> Is that the method that the upgrader uses? It seems that would handle a
> rename but might not handle a package that splits.
The big thing about the installer upgrade process is that it finds
orphan files and determines the new parent package for them. For
example, if package foo owned /foo/bar in 6.0, but there is no package
foo in 6.2, the installer notices that foo was installed on the system
but there is no new foo package on the CD. It then searches through
all the packages that ARE on the CD to see if any of them own a file
/foo/bar. If there is such a package, it is marked for upgrade.
rpm -Fvh also doesn't automatically add packages that are new and
required by packages already on the system. For example, if the 6.0
box has package foo installed, and in 6.2 package foo grows a
dependency for package bar, but package bar wasn't installed on the
6.0 box, the rpm -Fvh will not install it, and dependency will not be
satisified. RPM will just exit without doing anything in this case.
Finally, rpm -Fvh doesn't automatically add packages that are
available that obsolete packages that are installed on your system.
For example, if package foo was installed on 6.0, and package bar in
6.2 obsoletes package foo, the installer automatically adds package
foo to the upgrade set. rpm -Fvh doesn't.
Cheers,
Matt
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
