Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1909801
Summary: | fprintd links against libnss3.so and libnssutil3.so but does not depend on nss and nss-util | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Adam Williamson <awilliam> |
Component: | fprintd | Assignee: | Benjamin Berg <bberg> |
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | bberg, fweimer, kdudka, robatino |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | openqa | ||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-12-21 17:45:39 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: | 1829024 |
Description
Adam Williamson
2020-12-21 17:08:40 UTC
Proposing as a Final blocker per https://fedoraproject.org/wiki/Fedora_34_Final_Release_Criteria#System_services - "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present." Yeah, that seems odd. libfprint depends on nss and should pull it in, but fprintd should certainly not link directly against NSS. Oh, hey, I know why this bug just appeared: it's because mstransky set Firefox to use internal nss because of https://bugzilla.redhat.com/show_bug.cgi?id=1908018 . Previously this bug was camouflaged by Firefox pulling in nss. Yes, even on Server - for some reason the default Server package set includes Firefox, that's odd, I'll have to try and figure out why. We're actually hitting this on Workstation too, because apparently Firefox was the only thing pulling nss into Workstation's default package set. The other thing I didn't understand here is why no auto-generated dependency happens. Is it because these libs are unversioned, perhaps? libfprint doesn't depend on nss or nss-util either. The dependency is actually there: https://koji.fedoraproject.org/koji/rpminfo?rpmID=24271679 The problem is that firefox provides libnss3.so()(64bit), but does not install the DSO in the directory searched by glibc: https://koji.fedoraproject.org/koji/rpminfo?rpmID=24364770 That's arguably a bug in the dependency generators: by default, they should only consider directories searched by default. aha, yes, thanks Florian, I missed that. So the problem is still the change in Firefox, but for a slightly different reason. It's wrong (others have noted this already) that the Firefox build provides the libnss deps, since it's not intending its copy to be system-wide. The packaging guidelines say that such provides should be filtered out by the packager. There's already a bug report for that - https://bugzilla.redhat.com/show_bug.cgi?id=1908791 - so this ultimately can just be treated as a dupe of that, I guess. *** This bug has been marked as a duplicate of bug 1908791 *** > The packaging guidelines say that such provides should be filtered out by the packager.
Why is it better to rely on human factor to explicitly filter out non-applicable provides when the dependency generator script can be fixed not to produce them by default?
(In reply to Kamil Dudka from comment #7) > > The packaging guidelines say that such provides should be filtered out by the packager. > > Why is it better to rely on human factor to explicitly filter out > non-applicable provides when the dependency generator script can be fixed > not to produce them by default? I expect it will break a few packages which install shared objects in non-default paths, along with a configuration file in /etc/ld.so.conf.d. I don't quite understand the reason for that approach (rather than using /usr/lib64 directly). |