DNF as default package manager

[Nico Kadel-Garcia]

> On Jan 21, 2015, at 8:00, Jan Zelený <jzeleny at redhat.com> wrote:


> Also I'd like to point out that if two packages offer the same provide, by 
> definition it means they are 100% exchangeable from the perspective of that 
> functionality. 

This is very, very wrong.  Even minor differences in packaging and API can break stable configurations when they occur without notice. The classic example is "mysql-libs", which every MySQL fork includes and which are incompatible with components from other forks, and for which updates cause mixed updated from different major forks. Hilarity ensues.

> 
>>> 2) It is easy to fix if you know it happens
>> 
>> When rel-eng is doing a mass rebuild of 18K+ packages how are we
>> suppose to know it happens?
> 
> You are not supposed to know this. It's supposed to be fixed in rawhide long 
> before you get to it.
> 
>>> 3) DNF is not going to change, so it must be fixed in packages anyway.
>> 
>> So there's known issues your not going to fix and, from the comment
>> below, you don't know if there's other similar issues or ones that
>> might be worse?
> 
> This interpretation is unfair to people who work on dnf. If there is an issue 
> that is clearly a bug and not just a difference in expectation, it will be 
> fixed. If it's the latter, it needs some discussion first. Vit is correctly 
> pointing out that dnf is not yum and you should therefore not expect it to 
> behave the same in every situation.
> 
>>> I'd be glad if somebody of rel-engs can give us the list of packages
>>> which suffers similar issues.
>> 
>> Are we expected to cross referencing previous logs to see if there's
>> changes or if it's the same and provide you that information? We
>> already have too much to do so it's easier to stick with yum where we
>> know what the outcome is. Sorry, not going to do your work for you!
> 
> Again, this is a bit unfair. Nobody asked you to do his work for him. We would 
> just appreciate your help. We would like you to work with us, not for us.
> 
> Thanks
> Jan
> -- 
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct