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