On 2014-01-17 10:26, hcvv wrote:
> So the only difference is configuration files.
And that you automatically get the same list of packages, or their
replacements, when they are system services.
> But my assumption is that automatic upgrading configuration files of an
> application may be done correct when you upgrade one version of an
> application. But the application version jump in this case will probably
> be as large as that of openSUSE. And application maintainers do not tend
> to support all those jumps accumulative.
I have been upgrading my system continuously since 1998, and it works.
When they don’t, you have to compare the old and the new files, and
choose what to port from the old to the new config. Granted, this is the
same as for a new installation, with a backup of the old /etc. But, the
upgrade procedure automatically generates a list of what files you have
My trick is to use “meld”, from KDE. It is an editor that opens two
files side by side, comparing them. With a single click you can copy
entire paragraphs from one file to the other, in any direction, or erase
blocks… very nice utility to migrate plain text configs.
> I would not take the chance. In any case, as a system manager you would
> have notes/backups on how you organised the system (I backup /etc on all
> systems, to be able to consult them after an update/upgrade/new
AHH! But that is a crucial step that many people don’t do. And those
that do are often not that strict as to be completely reliable. If you
miss a service not installed, a configuration file different from default…
Of course, you can run an rpm query to find out what config files differ
from the default configs, previous to install the new system.
> You also have to check if any newer version of
> application/database software has new/depricated functionality to begin
> with. In that whole process the keeping of old configuration files on
> the system can even be more of a burden. And it leads to old rubish in
> the system.
Well, that is the same case as many do: simply copy over the config
files from the old backup, without thinking.
The process is the same for a new install replacing an old one, as for
an upgrade in place: you have to review all configs. The advantage is
that it is working earlier, as you continue the review. Or, you can do
the review previous to the upgrade to save time.
Another strategy is to install a new server side by side the old one,
replicating all services one by one. When done, switch over. If it
fails, the old one is still available…
> But you can manage your systems in your way. I only advised the OP based
> on my experiences.
Same as I do
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)