[wplug] Upgrades and updates - was: SLES 9.0 questions

[Vanco, Don]

>-----Original Message-----
>From: wplug-bounces+don.vanco=agilysys.com at wplug.org 
>[mailto:wplug-bounces+don.vanco=agilysys.com at wplug.org] On 
>Behalf Of Robert E. Coutch
>Sent: Tuesday, October 26, 2004 11:02 PM
>To: wplug at wplug.org
>Subject: [wplug] Upgrades and updates - was: SLES 9.0 questions
>
>
>Hi all,
>
>Since this is going a bit off topic from the SLES 9.0 
>discussion, I though a 
>new thread would be proper.
>
>The topic of updating a system usually leads to a dicussion of 
>dependancy 
>problems and of apt, rpms and such.
>
>So let's get a little philosophical.
>
>If you upgrade a system running some distro (say SuSE 9.0 for example),
>by resolving all sorts of dependencies to install some new or 
>updated package 
>of some program you can't live without, are you still running 
>SuSE 9.0 ?
	IMO: yes, because it's the distros' core package profile that is
the cause for dependencies unique to a given package on that OS


>It seems SuSE makes updates (for packages) available via YAST 
>but these 
>updates are usually bug fixes for the version they packaged with 9.0.
>
>If you go around the updates they provide by upgrading with 
>the latest version 
>that requires other packages to be upgraded, you're affecting 
>the way your 
>system will handle updates from SuSE.
	The underlying issue here is that to provide that upgrade which
fixes the bug or security issue in question you've got a new package
that's been built against new libraries and development tool that are an
inherent part of the fix.  And it's usually this framework that is a
major cause for dependency issues.
	Further, as packages mature they sometime have components that
are split off into separate packages for any number of reasons.  This is
the worst when Distro A and Distro B decide to take different views
(i.e. Distro A does a split of package foo, but Distro B does not).
This was even an issue between RH 8 and RH 9 - there were quite a few
package splits and it caused great confusion / much gnashing of teefs.

>
>Sometimes you can upgrade a package because your system meets 
>the minimum 
>requirements of the package. I'm sure everyone here has done 
>this a few times.
>
>I'm mostly a SuSE, Red Hat, Fedora and Mandrake person so 
>here's what I usually do.
>
>I run my system as stock (no upgrades) as possible and just 
>apply the updates 
>from said disto suppliers via Yast(YUM) up2date, etc.
>
>When some great new upgrade comes out for a program I just 
>gotta have and my 
>system won't support it, I look at upgrading to the latest 
>version of my distro that will.
	Don't take this as a "No Duh!" comment, but yeah, that's pretty
standard fare IMO...

>I've been running distros about a year or more before 
>upgrading the whole 
>thing. Something like this: Ver 7.1 to ver 8.1 to ver 9.1 
>skipping the ones 
>in between (7.2, 7.3, 8, 8.2, 9) because I'm happy with my setup and 
>software.
>
>Are the Gentoo, Debian and BSD folks different?
	Ohhhh - I see what you're getting at.....

>Do they issue a command and  --POOF--  all their software is upgraded?
	To a certain degree, yes - but you can always experience
potential issues when packages make a major leap in functionality (like
X) or if you're trying to leap too far into the future.  All distros
have a life cycle, and I am of the opinion that "quantum leaps" in
revisions via upgrade will be major cause for nightmares -vs- doing a
fresh install.

>Or, do we all say at some point "It's time to move to the next/latest 
>version"?	
	I'll let those users comment - but Debian, Gentoo, and
especially FreeBSD do not suffer the "revision envy" common to RPM based
distros.  Criteria for a jump in revision is an interesting thing - and
the commercial distros (i.e.those that have a Marketing department
somewhere) seem to have a very open interpretation of what is cause for
a leap.  Red Hat Enterprise Linux is a prime example of how bad a
revisioning schema can be when you let marketing people handle it -
e.g.: RHEL 2.1 is currently on "Update 5" - but it's still called RHEL
2.1 (when, IMO, it's really RHEL 2.6 {2.1 plus 5 subsequent releases})
this is a "really big deal" because there are ISV packages out there
that are certified against "Update 2" but not against "Update 5" -  and
far too many of those ISVs don't bother to make that distinction in
support statements - they just say 2.1 and then I have to spend an hour
finding out what really is supported.  It's getting better (because so
many have screamed bloody murder at IBM, H-P, and Red Hat) but it's a
really, really stupid way to revision a distro.  RH used to have really
logical criteria for major/minor revision jumps - but those days are
gone.
	Debian is somewhat unique in that it's really what you make of
it (server -vs- desktop) so many will say yes and an equal amount will
say no to continual upgrades.  Likewise, FreeBSD historically was more
of a server OS and until recently lacked a lot of the functionality /
niceties desktop users required - and server guys just don't do upgrades
if things are not broken.

	Overall I'd say that too many Linux users are stuck in a Windows
patch mentality.  Two things I constantly have to work with my customers
to get them to understand: trim the OS install to meet the requirement,
and once it's working don't upgrade unless you know the upgrade in
question is a "must have" for the system in question.  Seriously - I get
5 emails a day for my SLES9 install - and I have not installed an update
since August 'cause I don't need what they fix or provide.

Don