DNF as default package manager

[Peter Robinson]

>> Isn't it? In the build system I suspect you'd either get:
>> 1) a failed build
>> 2) a package without ruby features
>> 3) something unexpected
>>
>> It might not be a show stopper for a standard package install but it
>> is for reproducible builds
>
> Why wouldn't you get reproducible builds? The fact that dnf resolved deps
> differently than yum does not mean you will not get the same result from it
> every time.
>
> 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. Therefore DNF doesn't technically do anything wrong by using
> different package with the same provide. Sure, the big picture might be a bit
> more complicated than that but that's something that can't be fixed overnight.

I realise it's all big and complex and there's special cases that need
to be taken into account but ultimately release engineering need to
ensure that the distribution is usable and works and hence changes for
things like yum -> dnf for build systems aren't taken lightly because
we can't fix it on the go like and end user who might get jruby vs
ruby.

>> > 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.

Correct, and hence we won't change the default in mock for builds
until we are certain it's all OK.

>> > 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 never ever insinuated that dnf is yum but if there's expectation or
interpretation of the status quo that is changed, or incorrect, in the
move from one to the other it needs to be fixed. Whether that's
changes in dnf, or packaging or an education of how things are done
that needs to be lead by the dnf developers to ensure it's as smooth a
change over as possible. If that's reaching out to packaging committee
to get things changes, analysis on packages and associated bug reports
it has to be done and saying "it's not a bug with dnf" doesn't get
people on side for the change. Ultimately someone needs to do the work
and like a rebuild of packages due to a soname bump the onus tends to
be on the people making the change.

>> > 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.

Rel-eng is happy to help when we have time to do so but the attitude
has generally appeared to be "it's not a bug in dnf it's not our
problem to fix so someone else has to do it" and from above it
appeared to be inferred that it's someone else's problem which is just
as unfair.

Peter