Re: Nope... it isn't just you...

1) Thanks for the dig - I can't read your mind.

2) Any system that has detailed dependency requirements such as you listed will need "hand" administration, in some form. From working very closely with SuSE 6,7, and 8, I can tell you that it is tightly delivered - so system dependencies are extremely well-handled. This I think is the Linux incarnation of good German engineering practice.

Now, for your issues:

1. Postgresql version MUST not change, nor can the build be differently compiled or built.

You pause the update to manually deselect anything that would break the DB. If something else you are trying to install *requires* a new version of the DB, the installer will inform you and you will have the choice of living without that, or forcing the install of it (taking chances). The key point here is the skill of the SuSE staff at identifying dependencies. I've seen numberless tweaks that SuSE makes of some or another package - in good GPL form - in order that it can live under YaST and its modules.

2. The CEO want's to brag and demands the OS be updated to latest "FOO" version of "BAR" distribution.

If you know that will break something, tell him, and if he insists, show him you weren't kidding.

3. Use ONLY the "system package management tools" GUI or otherwise (YaST == SuSE, RPM == RedHat/Mandrake, APT/DPKG == Debian, emerge == Gentoo, etc...)

4. Keep the system up and running PERFORMING it's service or function while being updated

I expect massive uptime on my x225. I'm sure I'll be tweaking it. I don't forsee big issues.

5. Do this without breaking your system.

I've had issues with hardware on Linux, but I've never had issues with SuSE administration. It started out good and just gets better, and is CONSISTENT across big version changes (at least since v.6).

6. Get it done in a reasonable fashion.

7. Manage the problem's as they occur inline with the upgrade without a break in the upgrade, therby not possibly having an UNUSEABLE/UNBOOTABLE system in the process.

The only times I ever destroyed a system like that were a) forgetting to run LILO b) deleting the wrong kernel image after an upgrade - whatever distribution, you should protect yourself against stupidity (like deleting bash.bashrc, which I did today).

8. Recover from a critical/fatal issue, requiring a break in the upgrade to fix the issue and continue from where you were

SuSE simply does not break during installs, and you can do a "manual" install where every action is run past you. But, it's always possible to screw something up, right? All I can say is, I've used admin tools on AIX, Sun, HP, and Digital, and even going back to Apollos and CRDS, and SuSE has the best administrative interface of all of them.

9. Go home at a decent time.

One hopes.

Answer the questions. Not what your feeling is.

I asked specific questions, Do you need me to expanded the detail to the point of childishness? If you could just ANSWER those questions, it'd be grand.

Unless you can't.

And we are Dwebians, Snobbians, Deb-O-Snobs for a reason. That, which you'll never quite understand. Mainly due to your slant of US vs. THEM. Debian goes to the CORE of what OSS really means. It goes so far as to HELP those projects and packages associated to it's Linux flavor as to comform to a set of guidelines. RPM is a similar set, as to HOW to package, but Debian goes a bit further, stating not only HOW to package but HOW that package is submitted and HOW and WHERE the files associated with that package needs to install to and how it's to be managed. also, the quality Control that packages go through. Options in something like Postgreql, are usually packaged seperately as they are options. They are compiled at the same time and packaged at the same time, but made seperate from the Primary.

Welcome to IWETHEY!