dnf versus yum

[Reindl Harald]

Am 09.01.2014 19:58, schrieb Ian Malone:
> On 9 January 2014 15:13, Toshio Kuratomi <a.badger at gmail.com> wrote:
>>
>> On Jan 9, 2014 6:26 AM, "Chris Adams" <linux at cmadams.net> wrote:
>>>
>>> Once upon a time, Toshio Kuratomi <a.badger at gmail.com> said:
>>>> <nod>  Just have yum drop a config file in there that protects the
>>>> kernel
>>>> rather than protecting the kernel if some other package chooses to
>>>> protect
>>>> something else.
>>>
>>> The magic "don't delete the running kernel" can't be done with just a
>>> config file.  Something has to detect which kernel version is running
>>> and match it to an RPM, and then protect just that version of multiple
>>> installed kernel RPMs.
>>>
>>
>> Can't the meaning of a package name in the config file simply mean: "make
>> sure one of these packages is always installed"?
>>
>> That won't protect the running kernel but it will protect a kernel (probably
>> the latest installed).  That would seem to address hreindl's use case of
>> wanting to test on multiple systems and when satisfied that things are
>> working cleanup all older packages.
> 
> Latest installed is almost exactly not what you want, I've had plenty
> (where plenty in this case is probably >5) of cases where a kernel
> update broke something, in quite a few of those cases to a state where
> the system wouldn't boot. If the most recent one is retained then
> you've still got a kernel, but not one that will actually run. With
> current behaviour I can still let my system update until a fix appears
> because I know it won't remove the good kernel. If updates can remove
> the running kernel then you have to watch each one carefully. Unless
> I've misunderstood this thread and this does not apply to automatic
> updates.

as thread starter: you have *correctly* understood the intention

your example shows once more how important it is that the
kernel is treatet special, hence i even did not think about
this case while i was often happy about it because after some
years the current behavior is somehow self-evident
	

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140109/670726f7/attachment.sig>