hello

[Michael Powell]

Julian Fagir wrote:

[snip]
> 
>> But, the question is quite clear, though I have no idea why [s]he
>> wants to do that downgrade and might want to explore that before
>> encouraging that move.
> That was what I was looking for, and for what was already done and how the
> system is usually updated (binary, sources) or if it was ever updated, and
> what the system does, i.e. which software is installed.
> And even why it shall be 7.2 or 7.1 and nothing newer.
> 
> 
> Regards, Julian

Language difficulties are problematic by themselves, but most professionals 
are not concerned with this as long as the information is there with which 
to address the actual problem.

There are several methods for upgrading systems and they essentially break 
down into two categories - binary or source. I am fairly unfamiliar with the 
binary approaches as I have always used the source-based method. I believe 
one caveat with the binary method is it only works with the GENERIC (the 
original kernel from the base install) kernel, so if you desire to run 
custom kernels the source upgrade process may be a better way to go.

The main point to be aware of is the ABI changes (and potential breakages) 
which occur when changing major version numbers, e.g., for example when 
going from 7.x version to 8.x version. When doing a source based upgrade 
(also known as "the make buildworld kernel installxxx..." dance) from one 
major version to the next you will need to rebuild all installed ports 
immediately after (and indeed as part of)  so that they will then be linked 
against the new major versions' libraries.

Mostly this process is driven by the need to upgrade, and there are actually 
compatibility shims which allow for running a previous version of an 
application (let's say an app limited to run only on 6.x or 7.x) on the 
newer operating system version.  An example would be to install the 
/usrports/misc/compat7x port on an 8.x machine in order to support an app 
designed for 7.x. Although this is only an example for illustrative 
purposes, it also may _not_ be applicable in your situation as it provides 
compatibility shims for 7.3.

So there are any number of available avenues open for you to choose from, 
and some reading on the upgrade procedures covered in the Handbook might be 
a good way to become more familiar in order to make a more informed decision 
on exactly which may be the best for your specific situation.

In addition to all the other upgrade methodologies which might actually 
allow for you to do an actual "downgrade" successfully, you may also wish to 
consider starting from scratch. I would tend to proceed in this direction if 
I was taking over a mess someone else had created. Many times a fresh OS can 
be installed, the application installed, and the previous configuration 
files and data can simply be copied to the new install.  This way you know 
everything about the machine you are now responsible for as opposed to never 
knowing for sure everything your predecessor may have screwed up.

First thing I do is study the situation and not make any changes to anything 
until I've figured out exactly what I need to do. Backups of all data is 
essential; I always dump everything so I can always recover back to a known 
good if something goes terribly wrong. First and foremost question I have is 
concerning the statement: "And even why it shall be 7.2 or 7.1 and nothing 
newer. "</quote>  We really need to understand this completely first. More 
details on this may be useful for potentially providing better advice.

-Mike

PS: I don't like any app which absolutely says it 'requires' a version of an 
operating system which may not receive security updates and whose End-of-
Life may expire before I need to stop relying on this application. Whenever 
I've seen this in the past it has most often been associated with bad and 
defective coding by whoever wrote the app, and nursing it along only pushed 
off into the future actually dealing with the problem of a broken app.