dnf versus yum

Reindl Harald h.reindl at thelounge.net
Sun Jan 5 08:40:38 UTC 2014



Am 05.01.2014 09:23, schrieb Mattia Verga:
> 
> Il 05/01/2014 00:13, Adam Williamson ha scritto:
>> On Sat, 2014-01-04 at 21:41 +0100, Alec Leamas wrote:
>>> On 2014-01-04 21:31, Lars E. Pettersson wrote:
>>>> On 01/04/2014 08:56 PM, Rahul Sundaram wrote:
>>>>> * yum remove kernel vs dnf remove kernel difference (unfiled? )
>>>> I found 976704, closed with 'Resolution: --- → UPSTREAM' in August.
>>>> Not sure what that means, but removing all kernels seem a bit odd and
>>>> at least the running kernel should be spared, in my opinion.
>>>>
>>>> <https://bugzilla.redhat.com/show_bug.cgi?id=976704>
>>>>
>>>> Lars
>>> Hej...
>>>
>>> Well, a lot of other (most?) folks have the same opinion - have a look
>>> in the archives for this thread....
>> It's a bit hard to tell, but from the comment it looks like it was
>> really closed as 'notabug' rather than 'upstream'.
> They really want to make dnf work this way.
> This is explained here:
> http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-packages-called-kernel

and that is clearly a regression

how likely is that somebody want to delete all kernels include the running one?
"the user can always specify concrete versions on the command line" - yes, at
the same time the user can "rpm -e --nodeps" if he really knwos what he is doing

the same for:
> protected_packages is ignored
> DNF drops Yum’s protected_packages configuration option. Generally, DNF lets the user
> do what she specified, even have DNF itself removed. Similar functionality can be
> implemented by a plugin

"DNF lets the user do what she specified" is nonsense, the system must not destroy itself
without *explicitly* specified this action via a *non-default* switch

-------------- 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/20140105/ad614640/attachment.sig>


More information about the devel mailing list