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. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list