F11 Proposal: Stabilization

[Ralf Corsepius]

On Wed, 2008-11-19 at 11:57 -0500, David Hollis wrote:
> On Wed, 2008-11-19 at 11:45 -0500, Seth Vidal wrote:
> > i
> > 
> > On Wed, 19 Nov 2008, Callum Lerwick wrote:
> > 
> > > No actually it's simpler than that. What we want is more like package
> > > holds. More precisely, we want the *opposite* of package holds.
> > >
> > > What we're talking about here is a mode where no packages are updated,
> > > except for security fixes, and a list of packages I know I want the
> > > latest and greatest of.
> > >
> > > Which is pretty much that command line up there, plus security updates.
> > > Except it's sticky. Really that's something that annoys the hell out of
> > > me about yum, nothing sticks. If a repo is broken and needs to be
> > > disabled, or if I want to 'hold' a package I know is broken, I have to
> > > go mucking about in config files. And that results in my repo files no
> > > longer being updated because they've been modified and RPM so helpfully
> > > starts spewing .rpmnew files all over...
> > >
> > > When are we going to get the ability to store arbitrary bits of
> > > information about packages in the RPM database? We just need a simple
> > > generic key=value system. So front ends can store stuff like what repo
> > > the package came from, 'is-dep' flags, hold flags, dont-hold flags, and
> > > so on, but RPM itself doesn't have to actually know or care what they
> > > mean.
> > 
> > If you want to do this now, you can, via plugins. What you're describing 
> > above is fairly painful, though. It ultimately works out to be a mechanism 
> > for excluding updates, though.
> 
> 
> Generally, if a package update is just a release-level bump, it's fairly
> minor change and isn't likely to affect anything.
Pardon, but that's not true. 

Any guess on a package update's severity based on a package's EVR is
just a random guess.

>   If the actual version
> portion changes (such as with the kernel, firefox, openoffice), there is
> a lot room for things to be affected.  What if yum/PackageKit had a flag
> to only update packages that only have a release bump.  

I fail to see the usefulness for this.

> I'm sure everyone can come up with a case where package-3.1.2-4 broke
> stuff that worked with package-3.1.2-3 though those would be fringe
> cases.
Exactly. You'd be missing all those tiny fixes packagers typically apply
to their packages. Sometimes, these may fix severe issues - You simply
don't know.

> I could be wrong.
> 
> In all reality of course, and as a lot of the folks on this thread
> already realize, is that if an effort to maintain stability is going to
> take considerable time and resources, it just isn't going to happen.
> That's why a lot of people don't like running EL5 or CentOS on their
> desktop, the bits don't get updated and you want all the new gee-whiz
> stuff.  I've converted all of my servers over to CentOS over the last
> year or so not so much out of stability issues, but rather not wanting
> to hvae to upgrade them every 6-12 months to stay current when
> everything is working just fine.
> 
> It really seems like that is pretty much how it's supposed to work to
> me.  Desktop/bleeding edge - go Fedora.  Stable, long-term support,
> servers doing standard server stuff - EL/CentOS.
I still think, people involved into this thread are mixing up things and
are using different definitions of "stable".

To me, "stable" means "run-time stable"/"applications work"/"system
doesn't break down", it doesn't mean "API/ABI stable" (such as CentOS),
nor choking package update streams/package maintenance workflow (What
others seem to be having in mind).

Ralf