Bug 1324623
Summary: | glibc: split libcrypt into separate package and package libcrypt-nss with NSS-based implementation | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Florian Weimer <fweimer> |
Component: | glibc | Assignee: | Florian Weimer <fweimer> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | aliakc, arjun.is, awilliam, codonell, dj, fweimer, jakub, law, mfabian, pbrobinson, pfrankli, pmatilai, redhat-bugzilla, robatino, siddhesh, tmraz |
Target Milestone: | --- | Keywords: | FutureFeature, Reopened |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | AcceptedBlocker | ||
Fixed In Version: | glibc-2.23.90-30.fc25 | Doc Type: | Enhancement |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-08-18 19:22:54 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1277284, 1338879 |
Description
Florian Weimer
2016-04-06 19:49:10 UTC
It seems this is not possible to do this with RPM directly because RPM cannot create subpackages with files with different contents under the same name. We could ship the DSO under different names and rely on ldconfig in %post to set up the proper symbolic link. I'm using distinctly named files in libcrypt and libcrypt-nss. Mark Wielaard pointed out that file conflicts interfere badly with debuginfo generation. The only remaining conflict is in the symbolic links. Those are now maintained by ldconfig and not stored in the package. DEBUG util.py:421: Unable to create appliance : Failed to build transaction : libcrypt-nss conflicts with libcrypt-2.24-1.fc25.armv7hl DEBUG util.py:421: libcrypt conflicts with libcrypt-nss-2.24-1.fc25.armv7hl DEBUG util.py:421: gstreamer-plugins-bad-free-0.10.23-31.fc24.armv7hl requires libvpx.so.3 DEBUG util.py:421: Unable to create appliance : Failed to build transaction : libcrypt conflicts with libcrypt-nss-2.24.90-1.fc26.armv7hl DEBUG util.py:421: gstreamer-plugins-bad-free-0.10.23-31.fc24.armv7hl requires libvpx.so.3 DEBUG util.py:421: libcrypt-nss conflicts with libcrypt-2.24.90-1.fc26.armv7hl The package conficts cause systems to not be installable The gstreamer brokeness is a different bug (In reply to Dennis Gilmore from comment #3) > DEBUG util.py:421: Unable to create appliance : Failed to build transaction > : libcrypt-nss conflicts with libcrypt-2.24-1.fc25.armv7hl > DEBUG util.py:421: libcrypt conflicts with libcrypt-nss-2.24-1.fc25.armv7hl > DEBUG util.py:421: gstreamer-plugins-bad-free-0.10.23-31.fc24.armv7hl > requires libvpx.so.3 > > DEBUG util.py:421: Unable to create appliance : Failed to build transaction > : libcrypt conflicts with libcrypt-nss-2.24.90-1.fc26.armv7hl > DEBUG util.py:421: gstreamer-plugins-bad-free-0.10.23-31.fc24.armv7hl > requires libvpx.so.3 > DEBUG util.py:421: libcrypt-nss conflicts with > libcrypt-2.24.90-1.fc26.armv7hl > > The package conficts cause systems to not be installable Please do not reopen existing bugs. This is probably bug 1360781. reopening again and proposing as a blocker bug, all arm images are broken, this is what introduced the breakage. It is appropriate to reopen a bug when when the fix causes issues We will not revert this bug as part of the fix, so this breakage really should be tracked somewhere else. I have asked for Fesco arbitration: https://fedorahosted.org/fesco/ticket/1611 This is really a bug in the installer image generation. If Fesco says we cannot use certain RPM features officially approved for general use in Fedora, we will comply. But we need a way forward to fix broken tools. (In reply to Florian Weimer from comment #7) > We will not revert this bug as part of the fix, so this breakage really > should be tracked somewhere else. > > I have asked for Fesco arbitration: > > https://fedorahosted.org/fesco/ticket/1611 > > This is really a bug in the installer image generation. If Fesco says we > cannot use certain RPM features officially approved for general use in > Fedora, we will comply. But we need a way forward to fix broken tools. Agreed, Fesco needs to make a decision. Thanks for filing the Fesco ticket. https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/thread/Q5LMMPVEORM76IOPGKYS4XJ6VZ2WLAAX/?sort=date Rich deps are not allowed, FESCo already made a decision (In reply to Dennis Gilmore from comment #9) > https://lists.fedoraproject.org/archives/list/devel-announce@lists. > fedoraproject.org/thread/Q5LMMPVEORM76IOPGKYS4XJ6VZ2WLAAX/?sort=date Rich > deps are not allowed, FESCo already made a decision But this is not a rich dependency (the stuff which involves and/or/if), it is a plain Recommends:, that is, a weak dependency. Temporarely quick and dirty solution for this is placing "libgcrypt" to the excludes list of yum (and tools related around it (mock ?, pungi ?). This might help for the time being, until Fesco decides. (In reply to Ali Akcaagac from comment #11) > Temporarely quick and dirty solution for this is placing "libgcrypt" to the libcrypt (In reply to Tomas Mraz from comment #12) > > Temporarely quick and dirty solution for this is placing "libgcrypt" to the > > libcrypt Yeah! Was a typo... Of course it's libcrypt. Per http://koji.fedoraproject.org/koji/taskinfo?taskID=15199953 this breaks compose of the ARM Xfce image. This is a release blocking image per https://fedoraproject.org/wiki/Fedora_Program_Management/ReleaseBlocking/Fedora25 , so this is an automatic blocker: "Bugs which entirely prevent the composition of one or more of the release-blocking images required to be built for a currently-pending (pre-)release" - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Automatic_blockers . So, marking as accepted. I believe https://pagure.io/fedora-kickstarts/pull-request/44 should be enough to at least work around this. For convenience in testing I found that livecd-creator (the old live image creator, superseded officially by livemedia-creator) has the same issue - trying to build an F25 Xfce live image with livecd-creator hits the exact same error. So I tested adding these lines: libcrypt-nss -libcrypt to fedora-live-base.ks and re-running the image compose, and it does make the libcrypt errors go away (the compose still fails due to the gstreamer issue). So I believe doing this for fedora-arm-base.ks should similarly work around the problem for ARM. It's not the greatest fix ever (like we don't have ENOUGH workarounds in kickstarts...) and it doesn't answer the question of how exactly this problem actually arises (what causes yum to decide it needs both libcrypt and libcrypt-nss?) but I think it should work. I'll look a bit further into yum's behaviour to see if a simple fix is possible on the yum side, if I can. pbrobinson merged the PR, so setting this to ON_QA; we'll see if it worked with the next compose. We're still not getting the image, because we haven't fixed the gstreamer bug: DEBUG util.py:421: Unable to create appliance : Failed to build transaction : gstreamer-plugins-bad-free-0.10.23-31.fc24.armv7hl requires libvpx.so.3 that needs to get filed as a blocker, it slipped my mind. But the libcrypt errors are gone, so I think we can close this. (In reply to Florian Weimer from comment #1) > It seems this is not possible to do this with RPM directly because RPM > cannot create subpackages with files with different contents under the same > name. It can nowadays, by using RemovePathPostfixes in spec. Dunno if its documented anywhere but see http://pkgs.fedoraproject.org/cgit/rpms/curl.git/tree/curl.spec?h=private-kdudka-libcurl-minimal for a practical example. |