Bug 1446494 - coreutils conflicts with coreutils-single
Summary: coreutils conflicts with coreutils-single
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kamil Dudka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-04-28 08:30 UTC by Ali Akcaagac
Modified: 2017-04-28 09:58 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-04-28 09:58:47 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Ali Akcaagac 2017-04-28 08:30:38 UTC
Error: coreutils conflicts with coreutils-single-8.27-3.fc27.x86_64
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

Please fix if possible!

*rawhide*

Please also see this in case of weak deps:

https://bugzilla.redhat.com/show_bug.cgi?id=1324623
https://pagure.io/fesco/issue/1611

We still depend on using *yum* because of limitations of *dnf* (and the huge refactoring it's going under now ... from what I believe it's happening).

Comment 1 Kamil Dudka 2017-04-28 08:37:25 UTC
coreutils intentionally conflicts with coreutils-single because those packages are mutually exclusive, thus cannot be both installed at the same time.  Please tell us what exactly you were trying to do when the error occurred.

Comment 2 Ali Akcaagac 2017-04-28 09:05:02 UTC
This is a bit tricky to explain!

We have a workflow set up (running for years over all iterations of Fedora, RHEL, CentOS) that coordinates package management for us. The center of all this is "yum" wrapped around with bash scripts.

This workflow checks for new packages available, reports conflicts, reports dependency issues, pulls in new packages (to specified directories). Deletes old packages (that has been replaced by new ones).

With other words, it keeps local copies of actual packages for various systems in certain directories. This is no repository or mirror or something like that, since it only keeps the least (minimal) required packages for a running system.

What it does is this (simplificated):

yum group install xfce-desktop                  \
                  --disablerepo=*               \
                  --enablerepo=rawhide          \
                  --releasever=rawhide          \
                  --downloaddir=/opt/packagedir \
                  --downloadonly

The desktop chosen her is just an example as well as using rawhide and downloaddir. These are usually placeholders and filled with the necessary information for the packages we download. We *rely* (mandatory) on downloaddir (which has never been introduced to dnf) to coordinate the packages destination.

Unfortunately yum has an incomplete (or errorous) implementation of weak dependency support. We would really like switching to dnf but unfortunately this is not possible. We've already filled a bunch of reports to dnf and even contacted the project-lead of dnf (and fedora) to find ways and solutions to solve this. It has been said (long ago), that *they* (dnf developers) intend to work on more compatibility to yum, so it won't cause irritations in other eco systems (This also affects other parts like return codes etc. (which we covered so far)).

As intitally said, yum is wrapped around bash scripts and been running here for years - without issues - in a closed eco system (company) serving packages to customers. We'd really like switching to dnf (as said). But as long as features are missing (downloaddir), way of processing with cached downloads, stalling during automated installation (where only a killall can help) and errorous resolve conflicts, we still rely on yum...

https://bugzilla.redhat.com/show_bug.cgi?id=1224908
https://bugzilla.redhat.com/show_bug.cgi?id=1382224
https://bugzilla.redhat.com/show_bug.cgi?id=1256313
https://bugzilla.redhat.com/show_bug.cgi?id=1393814

> weak dependencies in yum
https://bugzilla.redhat.com/show_bug.cgi?id=1360781

A not less amount of other bugreports has been closed instantly without even understanding the use case. We don't deal much with them anymore because of the frustrating situation.

Summarized: This is less an issue of coreutils rather than an issue of the toolchain that deals with package management. Please refer to #1360781 as well.

Right now I intend to explicitly place coreutils-single in the excludes list of yum. But bear in mind, that a few other toolchains in the Fedora eco system (your own), may fail composing ISO images etc...

Hope I was informative.

Comment 3 Kamil Dudka 2017-04-28 09:58:47 UTC
(In reply to Ali Akcaagac from comment #2)
> Summarized: This is less an issue of coreutils rather than an issue of the
> toolchain that deals with package management. Please refer to #1360781 as
> well.

So you have problems with dnf and/or yum.  It is not clear how the coreutils package could be improved in this regard.  There is only one weak dependency:

    Suggests: coreutils-common

... which does not seem to be related to the error in comment #0.  The conflict between coreutils and coreutils-single simply has to be there because both the packages install the same set of executables but with different contents inside.

> Right now I intend to explicitly place coreutils-single in the excludes list
> of yum. But bear in mind, that a few other toolchains in the Fedora eco
> system (your own), may fail composing ISO images etc...

To save you some time spent on debugging, you are likely going to have similar problems with curl conflicting with curl-minimal and libcurl conflicting with libcurl-minimal.


Note You need to log in before you can comment on or make changes to this bug.