Re: dnf replacing yum?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On 05/26/2016 08:45 AM, Valeri Galtsev wrote:
> 
> On Thu, May 26, 2016 5:17 am, Johnny Hughes wrote:
>> On 05/26/2016 04:31 AM, Yamaban wrote:
>>> On Thu, 26 May 2016 08:00, James Hogarth wrote:
>>>> On 26 May 2016 00:57, "SternData" wrote:
>>>>> On 05/25/2016 06:43 PM, Always Learning wrote:
>>>>>> On Wed, 2016-05-25 at 22:32 +0100, Timothy Murphy wrote:
>>>>>>
>>>>>>> Also, yum had associations which it was sad to lose.
>>>>>>
>>>>>> Perhaps the Fedora ("We love consulting all affected users")
>>>>>> replacement
>>>>>> could be named MUD.
>>>>>>
>>>>>> Now we await the System-D controlling interface ;-)
>>>>>
>>>>> There was much wailing and gnashing of teeth when these changes
>>>>> rolled into Fedora.  After a while, I got used to it and now it seems
>>>>> normal. Plus, if you type "yum update" it responds "what your really
>>>>> should type is dnf update, but I'll do it for you anyway".
>>>>
>>>> There was a mail on the Fedora development list recently from one of
>>>> the
>>>> internal Red Hat RHEL yum guys.
>>>>
>>>> It implied that in RHEL the command would remain yum and not change to
>>>> dnf,
>>>> although the internals will no doubt do so at some point.
>>>
>>> Well, from what I've heard from some Red Hat RHEL Kernel guys, it will
>>> be
>>> likely in RHEL 8.x as default with a yum compat cli, but unlikely to get
>>> into RHEL 7.x as replacement for yum, and should stay confined to EPEL.
>>> The reason given was: "(DNF is) not quite Enterprise ready, yet. Lets
>>> look
>>> again during Fedora 25".
>>>
>>
>> Based on previous RHEL history I would agree with Yamaban's take
>> (probably in RHEL 8.x, likely not in RHEL 7).  But Red Hat has been a
>> bit less conservative with making changes to RHEL 7 than they were the
>> previous version of RHEL.
>>
>> Still, for them to make a change there would need to be some driving
>> force for that change (IMHO).  For example, if there were new technology
>> areas (containers, cloud) where dnf had major functionality advantages
>> over yum, then they might consider a change.  Otherwise, I just don't
>> see it.
> 
> How about their recent agreements with Microsoft? That would be enogh
> driving force for them to account for all changes we observed so far IMHO
> (didn't look into dnf details so I exclude that for the moment from my
> comment...).
> 
> Valeri
> 

Well, striking an agreement so that RHEL can run on the Azure Cloud
(where SLES and Ubuntu and CentOS are already at) and on hyperv .. and
working with them to make Windows run better on KVM as a VM to me makes
perfect sense.  Other linux versions are already there (hyperv/azure)
and their customers want a paid RHEL option .. and people also need to
run Windows server for some things as a VM on RHEL KVM hosts.

I certainly don't want to start a flame war either way, but people with
customers need to do what their customers want .. and on both sides that
was for things to work together in their enterprise from both companies.

Of course, we can start a flame war and discuss how evil Microsoft is or
how evil money is or how evil global warming is or any other number of
things.  There will be many people on either side of all of those
positions .. but I'm not sure this is the forum for those discussions.

The bottom line for DNF, just like any other software that Red Hat
releases is .. if they build it and make it the default in RHEL, it will
become the default in CentOS .. we don't political or linux religious
wars (like systemd, selinux) here.  We build whatever source code Red
Hat releases when they release it.  Nothing more and nothing less.

>>
>> But, I have been wrong before .. a lot .. so take that with a grain of
>> salt :)

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux