Bug 1360781 - yum: does not support or ignore weak dependencies
Summary: yum: does not support or ignore weak dependencies
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: 26
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1366041 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-27 13:22 UTC by Ali Akcaagac
Modified: 2017-11-06 09:52 UTC (History)
21 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-06 09:52:09 UTC
Type: Bug


Attachments (Terms of Use)
error-log.txt (131.35 KB, application/x-gzip)
2016-07-30 19:20 UTC, Ali Akcaagac
no flags Details
error2-log.txt (1.08 MB, application/x-gzip)
2016-07-30 19:21 UTC, Ali Akcaagac
no flags Details
rawhide repo norarch (8.94 KB, application/x-rpm)
2016-07-31 16:49 UTC, Ali Akcaagac
no flags Details
plain rawhide repo file (1.94 KB, text/plain)
2016-07-31 16:50 UTC, Ali Akcaagac
no flags Details
my yum.conf file (122 bytes, text/plain)
2016-07-31 16:50 UTC, Ali Akcaagac
no flags Details
Output of fedpkg mockbuild (1.19 KB, text/plain)
2016-08-09 08:40 UTC, Zdenek Dohnal
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1324623 0 unspecified CLOSED glibc: split libcrypt into separate package and package libcrypt-nss with NSS-based implementation 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1428929 0 unspecified CLOSED fedpkg: “fedpkg mockbuild” uses yum unconditionally 2021-02-22 00:41:40 UTC

Internal Links: 1324623 1428929

Description Ali Akcaagac 2016-07-27 13:22:27 UTC
Error: libcrypt-nss conflicts with libcrypt-2.23.90-30.fc25.x86_64
Error: libcrypt conflicts with libcrypt-nss-2.23.90-30.fc25.x86_64
Error: libcrypt conflicts with libcrypt-nss-2.23.90-30.fc25.i686
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

Please fix if possible.

rawhide!

Comment 1 Carlos O'Donell 2016-07-27 14:19:13 UTC
(In reply to Ali Akcaagac from comment #0)
> Error: libcrypt-nss conflicts with libcrypt-2.23.90-30.fc25.x86_64
> Error: libcrypt conflicts with libcrypt-nss-2.23.90-30.fc25.x86_64
> Error: libcrypt conflicts with libcrypt-nss-2.23.90-30.fc25.i686
>  You could try using --skip-broken to work around the problem
>  You could try running: rpm -Va --nofiles --nodigest
> 
> Please fix if possible.
> 
> rawhide!

What did you run to get this error message?

How did you get into this scenario?

Could you provide the output of `rpm -qa | grep crypt` please?

Comment 2 Ali Akcaagac 2016-07-29 12:38:20 UTC
sudo yum group install gnome-desktop --releasever=rawhide --disablerepo=* --enablerepo=rawhide --downloaddir /opt/fedora --downloadonly

But the issue seem to be gone as I retried this today (just tested). Rather than -30 it now pulls in -29.

What I don't understand is, why the i686 packages are also being downloaded. I only have a x86_64 system. Must be triggered by another package... Will investigate and report back.

It looks like some package internal test got tested agains the i686 downloaded package and thus caused the error to happen.

Btw: I depend on yum because of reasons reported elsewhere... Should change with dnf 2.0 once out...

Comment 3 Ali Akcaagac 2016-07-29 15:34:28 UTC
I think I was able to isolate the *problem*! But first things first!

> What did you run to get this error message?

One of *our* (work) scripts triggered this issue a few days ago. On the 20th July we changed our infrastructure from Fedora 22 i686 to Fedora 24 x86_64 and continued running our scripts as usual. Early that morning one script triggered the error that I posted above.

The scripts basicly does the following:

sudo yum group install gnome-desktop --releasever=rawhide --disablerepo=* --enablerepo=rawhide --downloaddir /opt/fedora --downloadonly

sudo yum install <other packages> --releasever=rawhide --disablerepo=* --enablerepo=rawhide --downloaddir /opt/fedora --downloadonly

So all it does is downloading a set of groups and singular packages and stores them into a different directory. No further processing, no installation nothing. Just downloading.

> How did you get into this scenario?

I can not clearly answer this. All I can do is giving an explaination what may have caused this.

During my last replay (a few hours ago (Comment #2)), I detected that the directory where all packages got downloaded also contained i686 packages. I was quite curious, because none of the packages I had in the list were 32 bit. I believed them to be all x86_64 64 bit.

After looking close inside the directory I figured out that something has triggered 129 i686 packages along with nearly 2900+ x86_64 packages.

129 i686 packages that I cleary do not want and never triggered to be downloaded.

After going through the list of files (in small groups) I was able to isolate "wine x86_64" to be the cause. Wine (even called a x86_64 package triggered 129 i686 packages to be downloaded as well..

Amongst these packages there were glibc-2.23.90-30.fc25.i686.rpm and before that the group install gnome-desktop pulled glibc-2.23.90-30.fc25.x86_64.rpm package.

Now there are two packages of the same core library downloaded in the same directory. Side by side.

The first time - this probably (I can't redo the issue anymore because -29 is in the repository now) didn't trigger any issues. But running the two sudo command above again (a 2nd time) might have caused the x86_64 glibc package to trigger the issue with the i686 glibc package.

> Could you provide the output of `rpm -qa | grep crypt` please?

sure...

-bash-4.3$ rpm -qa | grep crypt
crypto-policies-20151104-2.gitf1cba5f.fc24.noarch
ccrypt-1.10-9.fc24.x86_64
libgcrypt-1.6.5-1.fc24.x86_64
cryptsetup-1.7.2-1.fc24.x86_64
cryptsetup-libs-1.7.2-1.fc24.x86_64
-bash-4.3$ 

and...

-bash-4.3$ rpm -qa | grep "i[0-9]86"
-bash-4.3$ 

No 32 bit packages in the list.

Comment 4 Ali Akcaagac 2016-07-29 15:41:56 UTC
I opened a bug for wine as well. Maybe they could explain why wine requires the x86_64 *and* i686 packages together. Basicly tries to install both versions.

https://bugzilla.redhat.com/show_bug.cgi?id=1361643

Comment 5 Ali Akcaagac 2016-07-29 16:06:03 UTC
A simple ...

dnf install wine

... causes the same architecture mismatch on my regular Fedora 24 system (Please note that this time dnf is used). Trying to download x86_64 *and* i686 packages ... including glibc ... the most likely possible trigger of above issue ...

Comment 6 Florian Weimer 2016-07-29 16:38:20 UTC
(In reply to Ali Akcaagac from comment #5)
> A simple ...
> 
> dnf install wine
> 
> ... causes the same architecture mismatch on my regular Fedora 24 system
> (Please note that this time dnf is used). Trying to download x86_64 *and*
> i686 packages ... including glibc ... the most likely possible trigger of
> above issue ...

I cannot reproduce this.  In any case, this is unrelated to the present bug report, which is about dependency issues related to libcrypt.

Comment 7 Ali Akcaagac 2016-07-29 17:03:38 UTC
(In reply to Florian Weimer from comment #6)
> I cannot reproduce this.  In any case, this is unrelated to the present bug
> report, which is about dependency issues related to libcrypt.

I might have been a bit unprecise here.

What I meant was this. Something triggered the libcrypt error that I reported in the initial bug report!

Now understand the situation that I am in. There was an error and I needed to figure out - the best way possible - to explain why and how this might have happened.

I was asked what exactly I did, that triggered this issue.

I replied, that we have an infrastructure running here (at work) that downloads groups of packages and individual packages. The two commands that did this were posted above.

The initial libcrypt error shows that somehow - and more importantly - why there was a mismatch (or clash or error or issue) between an x86_64 and i686 package.

The question here is - where did this i686 package came from ?

I believe that the x86_64 glibc package clashed with the i686 package (both downloaded in the same cache (or destdir) directory.

The is just theory because I was *not* able to reproduce it again.

Please also note that the version that clashed was 2.23.90-30 whereas I only receive 2.23.90-29 from rawhide now.

This still leaves the question  where on earth the i686 version of glibc came from.

It took me a couple of hours going from one package to another package (from the list of packages) to figure out that "wine" x86_64 pulled in 192 i686 packages.

This means *theoretically* that wine has triggered the i686 package of glibc and that *who knows* the x86_64 glibc has triggered the i686 glibc package... but as I said this is theory.

I tried to be as specific as possible and tried to manually re-do the steps that has been done automatically.

I can only offer this information. With glibc 2.23.90-29 (not -30) everything works perfectly.

The question why wine requires both packages has been issued in a different bugreport... and of course you are right ... is unrelated here ... but I wanted to mention this anyways.

Comment 8 Florian Weimer 2016-07-29 21:27:02 UTC
(In reply to Ali Akcaagac from comment #2)
> sudo yum group install gnome-desktop --releasever=rawhide --disablerepo=*
> --enablerepo=rawhide --downloaddir /opt/fedora --downloadonly

What's the version of yum you use for this?

> But the issue seem to be gone as I retried this today (just tested). Rather
> than -30 it now pulls in -29.

Please try again tomorrow, the rawhide repository should have -30 again.

Comment 9 Ali Akcaagac 2016-07-29 21:42:06 UTC
(In reply to Florian Weimer from comment #8)
> What's the version of yum you use for this?

-bash-4.3$ yum --version
Yum command has been deprecated, use dnf instead.
See 'man dnf' and 'man yum2dnf' for more information.

3.4.3
  Installed: rpm-4.13.0-0.rc1.27.fc24.x86_64 at 2016-07-25 15:47
  Built    : Fedora Project at 2016-04-25 13:45
  Committed: Lubos Kardos <lkardos> at 2016-04-25

  Installed: yum-3.4.3-509.fc24.noarch at 2016-07-26 11:09
  Built    : Fedora Project at 2016-02-05 12:35
  Committed: Fedora Release Engineering <releng> at 2016-02-05
-bash-4.3$ dnf --version
1.1.9
  Installed: dnf-0:1.1.9-2.fc24.noarch at 2016-07-25 16:00
  Built    : Fedora Project at 2016-05-24 15:43

  Installed: rpm-0:4.13.0-0.rc1.27.fc24.x86_64 at 2016-07-25 15:47
  Built    : Fedora Project at 2016-04-25 13:45
-bash-4.3$ 

> Please try again tomorrow, the rawhide repository should have -30 again.

Sure! If the issue happens again, then I will make sure to sent in log. At least something more descriptive.

Comment 10 Ali Akcaagac 2016-07-30 19:19:46 UTC
The problem is reproducable every time, when I enter:

sudo yum group install gnome-desktop --disablerepo=* --enablerepo=rawhide --installroot=/opt/fedora

... but ....

If I enter a different installroot then the problem won't show up:

sudo yum group install gnome-desktop --disablerepo=* --enablerepo=rawhide --installroot=/opt/test

So my guess is, that it triggers something when it parses "fedora" as keyword within the installroot parameter.

Please find attached a log generated by this command:

sudo yum -d 10 -e 10 --rpmverbosity=10 group install gnome-desktop --disablerepo=* --enablerepo=rawhide --installroot=/opt/fedora &> error-log.txt

... and ...

sudo strace -f -qq -o error2-log.txt yum -d 10 -e 10 --rpmverbosity=10 group install gnome-desktop --disablerepo=* --enablerepo=rawhide --installroot=/opt/fedora

Hope this helps.

Comment 11 Ali Akcaagac 2016-07-30 19:20:29 UTC
Created attachment 1185834 [details]
error-log.txt

Comment 12 Ali Akcaagac 2016-07-30 19:21:01 UTC
Created attachment 1185835 [details]
error2-log.txt

Comment 13 Florian Weimer 2016-07-31 15:51:06 UTC
(In reply to Ali Akcaagac from comment #10)
> The problem is reproducable every time, when I enter:
> 
> sudo yum group install gnome-desktop --disablerepo=* --enablerepo=rawhide
> --installroot=/opt/fedora

Please provide the .repo file this command uses.  I can't reproduce on Fedora 23 or 24.  “rawhide” is not among the repositories installed by default.

Comment 14 Ali Akcaagac 2016-07-31 16:49:10 UTC
(In reply to Florian Weimer from comment #13)
> Please provide the .repo file this command uses.

Sure!

dnf install fedora-repos-rawhide.noarch

fe884c59a4ff1ff301d9828aba8a0074  fedora-repos-rawhide-24-1.noarch.rpm

Find it attached:
c4002c0dc336b459a47b50d40441c1d4  fedora-rawhide.repo

More info:
The file /bin/yum-deprecated is being copied over /bin/yum to replace the dnf-wrapper!

I will also give you my yum.conf file. I keep the cache (downloaded files) which might be an idea ?

Comment 15 Ali Akcaagac 2016-07-31 16:49:47 UTC
Created attachment 1186121 [details]
rawhide repo norarch

Comment 16 Ali Akcaagac 2016-07-31 16:50:11 UTC
Created attachment 1186125 [details]
plain rawhide repo file

Comment 17 Ali Akcaagac 2016-07-31 16:50:46 UTC
Created attachment 1186130 [details]
my yum.conf file

Comment 18 Florian Weimer 2016-08-01 13:40:49 UTC
(In reply to Ali Akcaagac from comment #10)
> The problem is reproducable every time, when I enter:
> 
> sudo yum group install gnome-desktop --disablerepo=* --enablerepo=rawhide
> --installroot=/opt/fedora
> 
> ... but ....
> 
> If I enter a different installroot then the problem won't show up:
> 
> sudo yum group install gnome-desktop --disablerepo=* --enablerepo=rawhide
> --installroot=/opt/test

I cannot reproduce the dependency on the directory name of the installation root.

I don't see a cross-architecture conflict, either.  I can install both i686 and x86_64 packages at the same time (but I have to choose whether I want to libcrypt or libcrypt-nss, I cannot have both).

In any case, this works fine with dnf, and libcrypt-nss is chosen as expected.  This is a bug in the yum dependency solver.

Comment 19 Zdenek Dohnal 2016-08-09 08:40:32 UTC
Created attachment 1189142 [details]
Output of fedpkg mockbuild

Hi,

I encountered the same error message as Ali when I was rebasing cups to newer version on fedora 25 branch. Attaching output, when I ran '$ fedpkg mockbuild'.

Comment 20 Zdenek Dohnal 2016-08-09 08:55:54 UTC
'$ fedpkg local' and '$ fedpkg build --scratch --srpm' works fine, but still problem with '$ fedpkg mockbuild'

Comment 21 Carlos O'Donell 2016-08-10 21:26:11 UTC
*** Bug 1366041 has been marked as a duplicate of this bug. ***

Comment 22 Chris Smart 2016-09-01 22:34:00 UTC
I got this problem trying to build a Fedora 25 live image using livecd-creator:

Error creating Live CD : Failed to build transaction : libcrypt conflicts with libcrypt-nss-2.24-3.fc25.x86_64
libcrypt-nss conflicts with libcrypt-2.24-3.fc25.x86_64

Comment 23 freebird1to1 2016-09-10 10:34:31 UTC
I have the same problem as Chris Smart above,
libcrypt conflicts with libcrypt-nss-2.24-3.fc25.x86_64
libcrypt-nss conflicts with libcrypt-2.24-3.fc25.x86_64
when trying to use livecd-creator

Comment 24 penthium2 2016-11-23 14:32:20 UTC
same bug as chris and freebird1to1 when I try every kickwtart with livecd-creator

Comment 25 Richard Vidal-Dorsch 2016-11-24 05:37:20 UTC
I hit the same bug...

Workaround is described here https://bugzilla.redhat.com/show_bug.cgi?id=1324623#c15

I add the following lines to fedora-live-base.ks

-libcrypt
libcrypt-nss

This solved the issue. However, I ran into another issue that is related to resize2fs.  It aborted with error -11 during resizing the FS image.
To fix this I rebuilt e2fsprogs-1.43.3-1.fc26.src.rpm for Fedora 25.
This is a temporarily fix.  I downloaded this package from Fedora build system.
Here is the URL:
https://kojipkgs.fedoraproject.org//packages/e2fsprogs/1.43.3/1.fc26/src/e2fsprogs-1.43.3-1.fc26.src.rpm
Fedora 25 is currently using e2fsprogs-1.43.1-2.
After upgrading e2fsprogs, the livecd built succeeded.

Comment 26 Nadav Goldin 2016-12-12 16:24:59 UTC
Hitting the same issue with mock on fedora25:

--> Processing Conflict: libcrypt-2.24-3.fc25.x86_64 conflicts libcrypt-nss
--> Finished Dependency Resolution
Error: libcrypt conflicts with libcrypt-nss-2.24-3.fc25.x86_64
 You could try using --skip-broken to work around the problem
Error: libcrypt-nss conflicts with libcrypt-2.24-3.fc25.x86_64
 You could try running: rpm -Va --nofiles --nodigest

Comment 27 Nadav Goldin 2016-12-12 17:10:22 UTC
Some more details, this happend when trying to install @buildsys-build group:

EBUG util.py:502:  Executing command: ['/usr/bin/yum-deprecated', '--installroot', '/var/lib/mock/fedora-25-x86_64-2474d86945a1de9c6d14549ec2401b9c-8291/root/', '--releasever', '25', 'install', '@buildsys-build', 'git', 'python', 'python-dulwich', 'python-setuptools', 'yum', 'yum-utils', '--setopt=tsflags=nocontexts'] with env {'PS1': '<mock-chroot> \\s-\\v\\$ ', 
....
DEBUG util.py:421:  Yum command has been deprecated, use dnf instead.
DEBUG util.py:421:  See 'man dnf' and 'man yum2dnf' for more information.
DEBUG util.py:421:  Error: libcrypt conflicts with libcrypt-nss-2.24-3.fc25.x86_64
DEBUG util.py:421:  Error: libcrypt-nss conflicts with libcrypt-2.24-3.fc25.x86_64
DEBUG util.py:421:   You could try using --skip-broken to work around the problem
DEBUG util.py:421:   You could try running: rpm -Va --nofiles --nodigest
DEBUG util.py:557:  Child return code was: 1
DEBUG util.py:180:  kill orphans

I tested it also with solely trying to install @buildsys-build group, and getting the same error.
A simple workaround is to add the 'libcrypt-nss' package in the same dnf/yum installation command.

Comment 28 Florian Weimer 2016-12-12 19:42:14 UTC
(In reply to Nadav Goldin from comment #27)
> Some more details, this happend when trying to install @buildsys-build group:
> 
> EBUG util.py:502:  Executing command: ['/usr/bin/yum-deprecated',
> '--installroot',
> '/var/lib/mock/fedora-25-x86_64-2474d86945a1de9c6d14549ec2401b9c-8291/root/',
> '--releasever', '25', 'install', '@buildsys-build', 'git', 'python',
> 'python-dulwich', 'python-setuptools', 'yum', 'yum-utils',
> '--setopt=tsflags=nocontexts'] with env {'PS1': '<mock-chroot> \\s-\\v\\$ ', 
> ....

You need to figure out why yum-deprecated is used.  The Fedora 25 package set is only fully compatible with DNF.

Comment 29 Ali Akcaagac 2016-12-12 20:00:42 UTC
(In reply to Florian Weimer from comment #28)
> You need to figure out why yum-deprecated is used.  The Fedora 25 package
> set is only fully compatible with DNF.

#27 is using mock which still depends on yum.

util.py: line 892

config_opts['yum_command'] = '/usr/bin/yum-deprecated'

package_manager.py: line 177

if os.path.exists('/usr/bin/yum-deprecated'):

Comment 30 rvcsaba 2016-12-17 18:06:59 UTC
Same problem here. I build live system:

Error creating Live CD : Failed to build transaction : libcrypt conflicts with libcrypt-nss-2.24-3.fc25.i686
libcrypt-nss conflicts with libcrypt-2.24-3.fc25.i686

Comment 31 Boleslaw Ciesielski 2017-01-09 02:17:57 UTC
(In reply to Ali Akcaagac from comment #29)
> #27 is using mock which still depends on yum.

I was running into the same issue, but using "mock --dnf" works for me.

Comment 32 Nadav Goldin 2017-02-04 16:51:15 UTC
(In reply to Florian Weimer from comment #28)
> (In reply to Nadav Goldin from comment #27)
> > Some more details, this happend when trying to install @buildsys-build group:
> > 
> > EBUG util.py:502:  Executing command: ['/usr/bin/yum-deprecated',
> > '--installroot',
> > '/var/lib/mock/fedora-25-x86_64-2474d86945a1de9c6d14549ec2401b9c-8291/root/',
> > '--releasever', '25', 'install', '@buildsys-build', 'git', 'python',
> > 'python-dulwich', 'python-setuptools', 'yum', 'yum-utils',
> > '--setopt=tsflags=nocontexts'] with env {'PS1': '<mock-chroot> \\s-\\v\\$ ', 
> > ....
> 
> You need to figure out why yum-deprecated is used.  The Fedora 25 package
> set is only fully compatible with DNF.

Thanks, using dnf indeed resolves the issue.
Though our infrastructure is built around el7 machines, which trigger various mock chroots (el7/fc23-25) and switching all of those machines to fedora is not an option. Adding this to the fc25 mock configuration allowed me to still use el7 host(with yum) to build fc25 chroots with mock:

config_opts['chroot_setup_cmd'] = 'install @buildsys-build libcrypt-nss'

I guess it made 'yum' resolve the weak dependency somehow, maybe by coincidence. 

So I think the subject of this BZ is still relevant, at least until el7(8?) gets dnf.

Comment 33 Florian Weimer 2017-02-04 22:44:17 UTC
(In reply to Nadav Goldin from comment #32)
> (In reply to Florian Weimer from comment #28)
>> You need to figure out why yum-deprecated is used.  The Fedora 25 package
>> set is only fully compatible with DNF.
> 
> Thanks, using dnf indeed resolves the issue.
> Though our infrastructure is built around el7 machines, which trigger
> various mock chroots (el7/fc23-25) and switching all of those machines to
> fedora is not an option.

mock in EPEL is supposed to use dnf if available.  This was fixed as bug 1405783.

Comment 34 Fedora End Of Life 2017-02-28 10:01:01 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Comment 35 Zdenek Dohnal 2017-03-01 13:48:06 UTC
Again same error as Ali in comment #0 when using 'fedpkg mockbuild', this time on f26 branch.

Comment 36 Florian Weimer 2017-03-01 14:28:15 UTC
(In reply to Zdenek Dohnal from comment #35)
> Again same error as Ali in comment #0 when using 'fedpkg mockbuild', this
> time on f26 branch.

Are you on Fedora?  This is most likely a local mock configuration issue.  You need to switch to DNF.

Comment 37 Zdenek Dohnal 2017-03-01 14:37:03 UTC
(In reply to Florian Weimer from comment #36)
> (In reply to Zdenek Dohnal from comment #35)
> > Again same error as Ali in comment #0 when using 'fedpkg mockbuild', this
> > time on f26 branch.
> 
> Are you on Fedora?  This is most likely a local mock configuration issue. 
> You need to switch to DNF.

Yes, I am. I forgot that mock will have some config file, where I can set '--dnf' as comment #31 says. Sorry for meaningless comment.

Comment 38 Florian Weimer 2017-03-03 16:02:43 UTC
“fedpkg mockbuild” can trigger such errors due to bug 1428929.

Comment 39 Ali Akcaagac 2017-04-28 15:19:59 UTC
More to come:

Please also add `coreutils-single' to the list of excludes as well as some other packages that will follow up (e.g. curl).

https://bugzilla.redhat.com/show_bug.cgi?id=1446494

I filled a bugreport for coreutils earlier this day (which got closed). I am not sure whether the owner understood that even Fedora toolchain is affected by this issue (tried to explain this).

So in case things break again. Be told which packages need to be excluded.

Comment 40 Ali Akcaagac 2017-11-06 09:52:09 UTC
I am going to abandon this report and mark it as closed. DNF now supports everything required for *our* tasks. If someone feel that this should stay open, then please feel free to reopen.


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