On Thu, Feb 10, 2022 at 03:54:28PM +0100, Petr Pisar wrote:
V Thu, Feb 10, 2022 at 03:19:18PM +0100, Zbigniew Jędrzejewski-Szmek
> can deal with that. But if they having conflicting files with
> declaring Conflicts, this is only detected after packages have been
> downloaded and results in a failed transaction and is generally bad UX.
> Recently I was installing a bunch of packages for the the
> tests, and I was surprised how many such packages we have:
> Error: Transaction test error:
> file /usr/bin/arping from install of
golang-github-j-keck-arping-1.0.2-2.fc36.x86_64 conflicts with file from package
> file /usr/bin/cbc from install of libcouchbase-tools-3.2.2-1.fc36.x86_64 conflicts
with file from package coin-or-Cbc-2.10.5-8.fc36.x86_64
> Such conflicts lead to subpar user experience… Should we make an effort to clean
We could add a new implicit CI test to check for the conflicting files. A test
similar to fedora-ci.koji-build.installability.functional. That would inform
packagers that their new build is missing the explicit Conflicts.
It's not trivial to do right now, because you actually need to
download all the packages to see the issue. (Though file names are
available in the metadata files, e.g. dnf install /some/path works,
so I guess it could be done without downloading packages theoretically.)
> Add Conflicts between those packages?
Yes. It's mandated by the guidelines
Yeah, but is is worth the effort? I could open a bunch of bugs, but
I don't want to do this if nobody wants to look at them anyway.