Bug 1286445 - util-linux vs. coreutils-single conflict
util-linux vs. coreutils-single conflict
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ondrej Vasik
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-29 10:24 EST by Ali Akcaagac
Modified: 2015-12-15 02:21 EST (History)
12 users (show)

See Also:
Fixed In Version: coreutils-8.24-105.fc24
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1286338
Environment:
Last Closed: 2015-12-15 02:21:56 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ali Akcaagac 2015-11-29 10:24:29 EST
+++ This bug was initially created as a clone of Bug #1286338 +++

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

Please fix if possible
Comment 1 Karel Zak 2015-12-02 04:12:03 EST
Should be fixed by coreutils update.
Comment 2 Ali Akcaagac 2015-12-04 06:18:02 EST
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
Comment 3 Pádraig Brady 2015-12-04 07:25:22 EST
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
Comment 4 Ali Akcaagac 2015-12-06 03:54:02 EST
> 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
Comment 5 Pádraig Brady 2015-12-06 05:45:06 EST
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.
Comment 6 Ali Akcaagac 2015-12-06 05:55:01 EST
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...
Comment 7 Pádraig Brady 2015-12-06 06:04:27 EST
Oh right. Yes we should add coreutils-single to an exclusion list for the group if possible
Comment 8 Pádraig Brady 2015-12-07 17:57:35 EST
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.
Comment 9 Ondrej Vasik 2015-12-09 07:09:47 EST
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...
Comment 10 Ondrej Vasik 2015-12-09 08:33:49 EST
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.
Comment 11 Dan Horák 2015-12-09 10:58:39 EST
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?
Comment 12 Ali Akcaagac 2015-12-09 11:04:52 EST
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.
Comment 13 Pádraig Brady 2015-12-09 11:29:57 EST
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.
Comment 14 Ondrej Vasik 2015-12-09 14:45:16 EST
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.
Comment 15 Ondrej Vasik 2015-12-09 14:46:19 EST
(shortest name and alphabetic order was the usual way how it worked e.g. for text-www-browsers (w3m preferred over elinks/lynx))
Comment 16 Michal Luscon 2015-12-14 08:12:28 EST
Hi, 

there is a draft regarding the package prioritization - https://fedoraproject.org/wiki/PackagingDrafts/ProvidesPreferences . I think the distribution preference approach could help here.
Comment 17 Pádraig Brady 2015-12-14 09:29:15 EST
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
Comment 18 Ondrej Vasik 2015-12-15 02:21:56 EST
As the package was built, I'll close that one RAWHIDE. Thanks Pádraig for build and Michal for pointer.

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