On Tue, Jun 13, 2017 at 10:25 AM, Rex Dieter <rdieter@xxxxxxxxxxxx> wrote: > Rex Dieter wrote: > >> Tom Stellard wrote: >> >>> I'm working on moving the llvm-devel sub-package from the llvm package to >>> a new llvm4.0 package, however, when I upgrade from the llvm sub-package >>> to the llvm4.0 sub-package, I am getting file conflicts. >> ... >>> Error: Transaction check error: >>> file /usr/include/llvm from install of llvm-devel-4.0.0-13.fc27.x86_64 >>> conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64 file >>> /usr/include/llvm-c from install of llvm-devel-4.0.0-13.fc27.x86_64 >>> conflicts with file from package llvm-devel-4.0.0-4.fc27.x86_64 >> >>> Is this a bug in dnf/rpm or am I doing something wrong with the spec >>> files? >> >> IMO, you're doing nothing wrong, it's a dnf/rpm bug. dnf is supposed to >> implicitly Obsoletes/replace older packages of the same name (in general, >> though there are exceptions like "kernel") > > Occurs to me you could avoid/skip relying on the implicit replacement, and > make it *explicit*, but adding > Obsoletes: llvm-devel < 4.0.0-13 > to the new llvm-devel subpkg > Implicit replacements are dangerous, and lead to weird special cases. It's far better to be explicit. I woudl argue that this was actually a Yum bug that people turned into a misfeature, and we should adjust and actually be explicit about when content changes so Obsoletes need to be in place. DNF already handles most of the YumObsoletes behavior, but implicit replacements are tricky. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
