On Wed, 19 Nov 2008, 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. 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 general, drawing conclusions based on the type of change in the e-v-r
of any package is a bad plan. There is just too much diversity in why or
how someone changes those.
-sv
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
