To increase robustness of glibc updates on systems without NSS requirements, it makes sense to shorten the dependency loop by splitting libgcrypt from the main library package and provide two versions, one based on the built-in algorithms (without any additional dependencies), and one on NSS (or maybe another certifiable cryptographic library that is more library-safe).
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.