-- 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
