Bug 1196724

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