DNF as default package manager

Jan Zelený jzeleny at redhat.com
Wed Jan 21 13:00:01 UTC 2015


-- snip --

> > 1) It is not show stopper
> 
> 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.

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


More information about the devel mailing list