[lug] Old copies of Fedora?

[Nate Duehr]

On 7/23/2010 1:45 PM, Kevin Fenzi wrote:
> On Fri, 23 Jul 2010 03:02:06 -0600
> Nate Duehr<nate at natetech.com>  wrote:
>
>    
>> All they need to do is the same thing the Debian did almost 10 years
>> ago... make it a *requirement* of developers that packages MUST
>> upgrade cleanly or warn the user that they cannot be upgraded and
>> that manual intervention is required.
>>
>> No, not every package DOES this 100%, but it's a RELEASE-CRITICAL BUG
>> if they don't.  Some don't get caught until after release.
>>
>> There are pre-installation and post-installation scripts built into
>> all of the major package management systems for a reason.  Developers
>> just need motivation to use them to keep breakage from happening
>> during upgrades...
>>      
> Sure, this is a great goal, but it's not all that easy in some cases.
> Do you have any links to what exactly debian requires here?
>    

Sure, it's in their developer guides, on their site.

(Sorry was away on vacation and just getting back to this.)

But of course, part of it is cultural, and that's not documented.  One 
culture is "don't break things, or at least warn the user" the other 
culture is "don't care that much, they can reload".  Of course, there 
are individuals within both groups who buck the general cultural norms, 
but the general norms are different.  Ubuntu and derivatives kinda 
change the base culture of Debian to "something different" and I've 
never watched/participated in their developer lists/etc... to make any 
judgment that would hold any water.

Fedora isn't "bad" in any way for having that culture, it's their stated 
goal... they're the test-bed, RHCE is the different culture/value 
proposition in that circle... it's the stable version(s) of things, 
usually.  Thank goodness for CentOS.

> Does it upgrade your database schema on upgrades of apps that need
> that? Does it modify your config files if you modified them in a way
> thats no longer compatible with the old version?
>    

There's some developer choices to make here, but it MUST warn you.  MOST 
packages split off user-changeable things from the generic settings that 
the package usually should maintain, such that it's pretty rare someone 
with zero knowledge of how a package SHOULD work would ever be caught by 
anything but their own changes.

> In the recent set of upgrades I did here to f13, the only thing I can
> recall that broke was squid. The config file format completely changed
> between the two versions and rpm saw that I had modified squid.conf and
> didn't replace it. I went in and looked at the .rpmnew file and docs
> and had it working again in about 5minutes. Doing that automatically
> would require some kind of config file parser and mapper...
>    

That's cool.  But yes, many Deb packages DO include that config file 
parser... and scripts to check things and try to fix them 
automatically.  Debconf and derivatives being the more "centralized" 
example, but there are package maintainers who do it "by hand" with 
their own smart scripts.

>    
>> "Must flatten box and reinstall at every release", is crap ... and
>> just like Windows... and we all know it.  No matter what distro or
>> package does it.  Quality desktop software should upgrade itself
>> cleanly, period... as a general rule...
>>      
> yeah, and in my experience it does these days. ;)
>    

Good to hear.  That wasn't my past experience, and typically still isn't 
with CentOS.  But it did finally do a clean upgrade that left DNS jacked 
up around the time version 5 released.  I was fairly impressed that it 
did the (mostly) right things.

> Of course not re-installing you miss out on some new things that can
> only be done at install time: new filesystems, new partitioning, etc,
> but the old setup should keep working.
>    

Yep. Understand.

> kevin
>    
>

If given the *choice*... I just like the culture of "let's TRY hard not 
to break it during upgrades" vs. the "let's cop out and they'll 
reinstall" -- and yeah, I'm overstating both positions to make the 
point... it's far more subtle than that.

:-)

Nate