F11 Proposal: Stabilization

[Seth Vidal]

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