Bug 1431408
Summary: | Should ignore /usr/lib/.build-id for hidden-file-or-dir check | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Paul Howarth <paul> | ||||
Component: | rpmlint | Assignee: | Tom "spot" Callaway <tcallawa> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | rawhide | CC: | carl, jaruga, jskarvad, j, kevin, mjw, paul, projects.rg, tcallawa, tmz, twoerner, ville.skytta | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2017-07-17 14:17:53 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: | |||||||
Attachments: |
|
Description
Paul Howarth
2017-03-12 09:02:13 UTC
Any pointers to rationale why that dir is hidden in the first place? (In reply to Ville Skyttä from comment #1) > Any pointers to rationale why that dir is hidden in the first place? That is a good question, but I cannot find the original rational. The ".build-id" directory has always been "hidden" from the start. The original design document (from 10 years ago now) just simply stated the name would be ".build-id". No rational given for the starting ".": https://fedoraproject.org/wiki/Releases/FeatureBuildId I think the original idea was that any directory that contained an executable or shared library could also contain a .build-id directory for the "magic symlinks" and so it was natural to start with a dot so it wouldn't clutter the normal file view. So then the system directories also started with a dot to be consistent. But that is just speculation. I suppose bug 1432372 makes this issue moot? (In reply to Ville Skyttä from comment #3) > I suppose bug 1432372 makes this issue moot? Maybe, maybe not. It might get resolved by fixing the conflicts and retaining the /usr/lib/.build-id directory. Let's see. Doesn't look like the hidden directory is going away, so the issue isn't moot. This rpmlint behavior in rawhide is confusing (e.g. bug 1401302): libarcus.x86_64: W: hidden-file-or-dir /usr/lib/.build-id libarcus.x86_64: W: hidden-file-or-dir /usr/lib/.build-id .. python3-arcus.x86_64: W: hidden-file-or-dir /usr/lib/.build-id python3-arcus.x86_64: W: hidden-file-or-dir /usr/lib/.build-id And the /usr/lib/.build-id doesn't seems to go away due to https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo Hi Jaroslav, If you want to improve the rpmlint's behavior, you can ask the upstream from below page. https://github.com/rpm-software-management/rpmlint Created attachment 1267014 [details]
Patch to accept /usr/lib/.build-id dirs in rpmlint
The attached patch makes rpmlint no longer complain about only-non-binary-in-usr-lib or hidden-file-or-dir /usr/lib/.build-id
Any news here? From rpmlint upstream POV: 1) Github pull requests are much preferred over patches in Bugzilla. 2) Maybe the only-non-binary-in-usr-lib issue is a broader one, so that the warning shouldn't be issued if there are only dirs and symlinks in /usr/lib. This seems to be the case for .build-ids. 3) The hidden-file-or-dir one is thus a separate issue, and should be treated in a separate patch/pull request. But do the dirs exist in any other distributions besides Fedora, RHEL and derivatives? If not, perhaps it should be handled in Fedora/EPEL rpmlint configs instead of upstream or patching. (In reply to Ville Skyttä from comment #10) > From rpmlint upstream POV: > > 1) Github pull requests are much preferred over patches in Bugzilla. I am happy to submit to the mailinglist (which one?) or setup a proper git repo and commit the patch for a git pull request. But I don't have a github account, so cannot do github pull requests. But if someone else wants to please feel free to take the attachment and submit it there. > 2) Maybe the only-non-binary-in-usr-lib issue is a broader one, so that the > warning shouldn't be issued if there are only dirs and symlinks in /usr/lib. > This seems to be the case for .build-ids. It looks like the same as the other entries in usr_lib_exception_regex, but maybe I am missing the point? > 3) The hidden-file-or-dir one is thus a separate issue, and should be > treated in a separate patch/pull request. But do the dirs exist in any other > distributions besides Fedora, RHEL and derivatives? If not, perhaps it > should be handled in Fedora/EPEL rpmlint configs instead of upstream or > patching. This is from upstream rpm (will be in the next release), so is not Fedora specific (Fedora just has an early backport and uses it first). This came up again recently on the devel@ mailinglist. Would be nice to get this patchlet in the fedora rpmlint package. (In reply to Tom "spot" Callaway from comment #13) > https://github.com/rpm-software-management/rpmlint/pull/107 Thanks. Looks like it was integrated (with a small fixup) upstream. Could it be backported to the fedora rawhide rpmlint package? rpmlint-1.9-11.fc27 is in rawhide with the upstream change applied. Please build with the applied patch also for f26. We see a lot of reviews from f26 stumbling upon this issue with the mentioned false warnings about build-id. |