Should be fixed by coreutils update.

Unfortunately It's not:

--> Finished Dependency Resolution
Error: coreutils conflicts with coreutils-single-8.24-102.fc24.i686
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

I noticed another issue with coreutils-single where it included the kill
utility, thus conflicting with util-linux.
This is fixed in coreutils-8.24-103.fc24

> Fixed In Version: coreutils-8.24-103.fc24

Do we speak about the same 103 ?

--> Processing Conflict: coreutils-8.24-103.fc24.i686 conflicts coreutils-single
--> Finished Dependency Resolution
Error: coreutils conflicts with coreutils-single-8.24-103.fc24.i686
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

Well the error in comment #4 is expected.
I.E. coreutils and coreutils-single are expected to conflict.
Generally one will not install coreutils-single, being only useful for embedded or specialized installs.

Well all I did was a group install and ended up by receiving this error which otoh leads to yum aborting further installation. Right now I am excluding coreutils-single from within command line. But this doesn't look like a clean and proper solution at all.

At the end, this shows up by issuing the following commands:

yum group install base-x                                        \
                  standard                                      \
                  core                                          \
                  dial-up                                       \
                  fonts                                         \
                  hardware-support                              \
                  multimedia                                    \
                  networkmanager-submodules                     \
                  guest-desktop-agents                          \

                  ...

And I don't see the point that a yum group install ends up in receiving an error, when it doesn't do anything else than processing a list of required groups for a normal desktop setup...

Oh right. Yes we should add coreutils-single to an exclusion list for the group if possible

I'm not sure what to do here TBH. Is there a fundamental dep solver issue with two packages that provide the same name but conflict with each other?
If that was the case we might have to build coreutils-single conditionally,
though that would be a surprising restriction.

Maybe we can add versioned obsoletes (Obsoletes: coreutils = %{version}-%{release}) in the coreutils-single subpackage (as it already has versioned provides - I think both can't be installed on the system anyway).
Exclusion from default group lists should be done anyway. This should probably be done through releng component, however I'm not 100% sure here...

Few notes from IRC chat with sharkcz who has a lot of experience with conflicts from alternative architecture builds...

<dhorak> I'm afraid this situation can't be solved. buildsys-build and Core groups need "coreutils", so dnf chooses something. Packages can have Requires:coreutils, dnf makes its choice, same for Requires:/bin/ls (and other file requires)
<dhorak> It is more about the dnf choice whats default and how to enable installation coreutils xor coreutils-single.

I think we need a word from the dnf/libsolv team after clarifying what is the situation and what are the intentions.

intention
- have coreutils and coreutils-single to provide the same set of tools and in general be swappable, so one could "force" coreutils-single into his system and still satisfy all deps that require "coreutils" or the individual files? Am I right?

I'd like to add that we are forced to use "yum" for infrastructure management. We'd like to switch to dnf, but unfortunately dnf doesn't provide the same capabilities as yum does right now (With other words: due to limitations of dnf). We are stuck with yum until missing features are implemented in dnf. So talking with the dnf/libsolv people won't be enough. The *resolving* thing has to work with yum as well.

Thanks for looking at this guys. @Dan yes we'd like coreutils-single not to be considered unless explicitly installed. I'm a bit surprised that yum/libsolv don't prefer the package name over a provides alias.  Also I purposefully didn't add explicit Provides: /bin/* so that coreutils was selected in that case, though I guess we have the same issue if one Requires: /usr/bin/...
@Ondrej re comment #9, perhaps we could use obsoletes in the reverse direction to give priority to the coreutils package? I.E. have the coreutils package Obsoletes: coreutils-single = %{version}-%{release}

If that didn't address the priority issue, then we'll probably have to move the coreutils-single subpackage to be only build conditionally.

Ali: libsolv/dnf and yum guys are basically the same team, so it doesn't really matter, but I agree this must work with both update managers.
Pádraig: I always thought shortest name wins when it comes to resolving, however, it seems that dnf somehow prefers the size of the package. I'll talk to the software management team to find out what options we have, maybe you are right and reverse direction obsolete might solve the issue.

(shortest name and alphabetic order was the usual way how it worked e.g. for text-www-browsers (w3m preferred over elinks/lynx))

Hi, 

there is a draft regarding the package prioritization - https://fedoraproject.org/wiki/PackagingDrafts/ProvidesPreferences . I think the distribution preference approach could help here.

Thanks for the info @Michal, very comprehensive.
Reading that implies we might add this to fedora-release.spec:
  Suggests: coreutils

However also suggested in the older referenced depsolving info
is that fact that obsoleted packages should lose.
Therefore the Obsoletes: coreutils-single should also work I think.
I've done that in coreutils-8.24-105.fc24

As the package was built, I'll close that one RAWHIDE. Thanks Pádraig for build and Michal for pointer.