Red Hat Bugzilla – Bug 1196724
[RFE] please add a file with the content equivalent to "rpm -ql filesystem"
Last modified: 2018-04-10 11:03:10 EDT
Use-case: Detect if particular item in particular path still belongs to filesystem package or already to the "leaf" package. This detection is handy if one doesn't want to hardcode particular path in the specfile (e.g., using "pkg-config --variable=completionsdir bash-completion" instead of hardcoding /usr/share/bash-completion/completions) but wants to own such path up to the boundary with filesystem-backed hierarchy, as per packaging guidelines). Note that using "rpm -qf -- $DIR" for such purpose of dynamic directory ownership within the specfile is not recommended, hence the next sane detection recipe would be grepping the requested file that filesystem package should provide (exactly for such "cannot use rpm -q[fl]" purposes). Example file location: /usr/share/filesystem/paths. Please not that filesystem package is somewhat special, where it would really make sense to have "rpm -qf" precached in the proposed way, no extension to the scope is considered.
I don't think this is something for RHEL 7. Directory ownership doesn't change too much within the major versions and it is very unlikely I'll drop some directory ownership from filesystem package in the RHEL 7 lifetime. Adding the ownership is much less dangerous, because at the worst case, there will be duplicate ownership (which already happens in many cases). In addition, I'm not very keen of having this file ... at this moment, rpm -ql filesystem on RHEL 7 shows 14k5 lines and more than 300kbytes - and I don't see that value in that.
> I don't see that value in that Scenario making such file valuable was provided: one should not call rpm -ql in the rpmbuild recipe.
Yes, in Fedora, it may make sense - still better than calling rpm in %post - however within the RHEL 7, "Detect if particular item in particular path still belongs to filesystem package or already to the "leaf" package." is not relevant... as I'm not going to remove any ownerships from the filesystem package there - more likely I'll add few more in RHEL 7 timeframe. Do I understand correctly that the primary usecase is to have the same spec files in Fedora and RHEL 7 and just having the conditions checking for the ownership?
re [comment 4]: > Do I understand correctly that the primary usecase is to have the same > spec files in Fedora and RHEL 7 and just having the conditions checking > for the ownership? Yes, that would work well for my use case. There can be more, especially if there's a goal for packages not to own directories, already owned by filesystem, superfluously. re [comment 6]: > however, as the ownership in RHEL doesn't change that frequently, I > don't see many reasons to have such file by default on all systems. Ownership may not change frequently, however there's no guarantee pkg-config response will not change because of the changes brought with some other package (and mind this is also part of my use case). Simply put, I want to put some flexibility into the package I maintain and resolving this bug would enable that. Few extraneous bytes shipped can hardly be seen as an obstacle (just implementing distro-wide license files deduplication will spare much much more). Regarding implementation, there's a possibility to use "%files -f $FILE" in the spec so as to ensure that $FILE indeed lists everything, and then either ship also pristine $FILE, or drop any spec-specific annotations (%dir, %attr, ...) first (preferable).
+1 to Kamil's suggestion. Ondro, do you think it's worth changing? (From QE POV yes; we would not lose anything by respin at this point. Also writing test would be a bit easier.)
Ok, I'll do a respin... makes sense... thanks for suggestions, Kamil...
Sory, the lists are not the same: --- by_rpmdb 2017-11-30 21:02:21.373816722 -0500 +++ by_file 2017-11-30 21:02:21.433816722 -0500 @@ -1,5 +1,3 @@ -/ -/bin /boot /dev /etc @@ -19,15 +17,12 @@ /etc/xdg/autostart /etc/xinetd.d /home -/lib -/lib64 /media /mnt /opt /proc /root /run -/sbin /srv /sys /tmp @@ -38,17 +33,10 @@ /usr/include /usr/lib /usr/lib/debug -/usr/lib/debug/bin -/usr/lib/debug/lib -/usr/lib/debug/lib64 -/usr/lib/debug/sbin /usr/lib/debug/usr -/usr/lib/debug/usr/.dwz -/usr/lib/debug/usr/bin -/usr/lib/debug/usr/lib -/usr/lib/debug/usr/lib64 -/usr/lib/debug/usr/sbin /usr/lib/games +/usr/lib/locale +/usr/lib/modules /usr/lib/sse2 /usr/lib64 /usr/lib64/X11 @@ -105,6 +93,7 @@ /usr/share/dict /usr/share/doc /usr/share/empty +/usr/share/filesystem /usr/share/games /usr/share/ghostscript /usr/share/ghostscript/conf.d @@ -14547,7 +14536,6 @@ /usr/src /usr/src/debug /usr/src/kernels -/usr/tmp /var /var/adm /var/cache @@ -14560,13 +14548,10 @@ /var/lib/misc /var/lib/rpm-state /var/local -/var/lock /var/log -/var/mail /var/nis /var/opt /var/preserve -/var/run /var/spool /var/spool/lpd /var/spool/mail Just catching few cases: * Some differences can be attributed to the fact that they are symlinks, but spec file explicitly asks for directories. Anyway, is this intended? * Also, there are files like /usr/lib/locale, which exist during build time but don't end up being owned by *any* package. Should they be? * Then there's /, * and /usr/share/filesystem: this is rightly owned by the new filesystem-content package: so should it be included? (Before you say 'yes', won't it break the universe?)
By the way, this is the list of symlinks in filesystem package (unchanged since last relase): /bin /lib /lib64 /sbin /usr/lib/debug/bin /usr/lib/debug/lib /usr/lib/debug/lib64 /usr/lib/debug/sbin /usr/lib/debug/usr/.dwz /usr/tmp /var/lock /var/mail /var/run
Thanks for the comments, Alois. I think / and /usr/share/filesystem should definitely be excluded. As for the symlinks created by post scriptlets included... that's good question - symlinks are not dirs and find command searches for dirs - however, it makes sense to look for the symlinks too. I'll fix the find command to include them. unowned /usr/lib/locale is imho bug, and same with /usr/lib/modules ... not new, though... but I can fix the ownership in the respin.
Nice. Just a nitpick, why / should not be included? It does belong to `filesystem` (checked on Fedora 26).
Ah, sorry, you are right, sorry for confusion, / should be included :) . I shouldn't write quick comments on Sundays :).
Verified by re-running new test. Looks fine.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:0838