F11 Proposal: Stabilization

David Hollis dhollis at davehollis.com
Wed Nov 19 16:57:26 UTC 2008


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.  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'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.

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.






More information about the devel mailing list