To upgrade or not to upgrade....
paul at city-fan.org
Mon Nov 6 18:03:40 UTC 2006
James Wilkinson wrote:
> Markku Kolkka wrote:
>> Fedora packages don't install anything in /opt, so it will be untouched
>> in an upgrade.
> I replied:
>> Unless the files are part of a third-party RPM that is (recorded in the
>> RPM database as being) dependent on a particular version of a Fedora
>> Core package. In that case, the upgrade will update the old Fedora Core
>> package, and try to upgrade the third-party RPMs to a version that *can*
>> co-exist with the new Core package. If it can't find any upgraded RPMs,
>> it will remove them, to keep the RPM database consistent.
> Paul Howarth asked:
>> Is this behaviour documented somewhere, since I have yet to see it after a
>> number of upgrades to FC6? I have yet to see a package removed as part of an
>> upgrade if it wasn't explicitly obsoleted by another package.
> Hmm. That's what I thought happened. I haven't explicitly checked this...
> # The installation overrides any third party packages which conflict with
> # the default installation set.
> which, to my mind, is not the clearest language.
I read that as "anaconda will ignore conflicts and dependencies that any
third party packages may have with the packages being installed", which
is pretty well how anaconda behaved before the yum backend was brought in.
> I'm sure I read something fairly definitive to this effect, but now I
> can't find it anywhere. Nor yet can I find any documentary evidence on
> the Web one way or another.
> I would maintain that Anaconda *ought* to remove packages if there's no
> other way to update Core packages, but without trying, I've no idea.
OOh, I certainly wouldn't like that. There may be proprietary/local
packages on there that need to be manually upgraded because the vendor
doesn't provide a repo that can be used at install time. I think it's
better to leave those in place and findable using "package-cleanup
--problems" rather than simply removing them so that the sysadmin has to
figure out what's gone and replace it. Although it might be easy as
looking in upgrade.log to see what was removed, it would be better not
to remove packages at all. For example, a package might have a bunch of
config files that need editing for the target system. Removing the
package will leave a bunch of .rpmsave files that need to be merged back
in when the new package is installed, whereas in many cases a manual
upgrade will not need that effort because the config files won't have
changed between releases.
More information about the users