Bug 1324623 - glibc: split libcrypt into separate package and package libcrypt-nss with NSS-based implementation
Summary: glibc: split libcrypt into separate package and package libcrypt-nss with NSS...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Florian Weimer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F25AlphaBlocker 1338879
TreeView+ depends on / blocked
 
Reported: 2016-04-06 19:49 UTC by Florian Weimer
Modified: 2016-08-19 04:36 UTC (History)
16 users (show)

Fixed In Version: glibc-2.23.90-30.fc25
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-08-18 19:22:54 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1360781 0 unspecified CLOSED yum: does not support or ignore weak dependencies 2021-02-22 00:41:40 UTC

Internal Links: 1360781

Description Florian Weimer 2016-04-06 19:49:10 UTC
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).

Comment 1 Florian Weimer 2016-07-21 12:44:57 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.

Comment 2 Florian Weimer 2016-07-22 15:57:46 UTC
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.

Comment 3 Dennis Gilmore 2016-08-09 14:57:45 UTC
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

Comment 4 Dennis Gilmore 2016-08-09 14:58:18 UTC
The gstreamer brokeness is a different bug

Comment 5 Florian Weimer 2016-08-09 15:00:50 UTC
(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.

Comment 6 Dennis Gilmore 2016-08-09 15:24:31 UTC
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

Comment 7 Florian Weimer 2016-08-09 16:09:50 UTC
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.

Comment 8 Carlos O'Donell 2016-08-09 19:49:57 UTC
(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.

Comment 9 Dennis Gilmore 2016-08-10 08:53:09 UTC
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

Comment 10 Florian Weimer 2016-08-10 09:03:44 UTC
(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.

Comment 11 Ali Akcaagac 2016-08-10 10:48:26 UTC
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.

Comment 12 Tomas Mraz 2016-08-10 13:33:25 UTC
(In reply to Ali Akcaagac from comment #11)
> Temporarely quick and dirty solution for this is placing "libgcrypt" to the

libcrypt

Comment 13 Ali Akcaagac 2016-08-10 13:41:33 UTC
(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.

Comment 14 Adam Williamson 2016-08-10 20:41:50 UTC
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.

Comment 15 Adam Williamson 2016-08-15 21:04:09 UTC
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.

Comment 16 Adam Williamson 2016-08-15 21:12:30 UTC
pbrobinson merged the PR, so setting this to ON_QA; we'll see if it worked with the next compose.

Comment 17 Adam Williamson 2016-08-18 19:22:54 UTC
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.

Comment 18 Panu Matilainen 2016-08-19 04:36:58 UTC
(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.


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