Bug 894202

(In reply to comment #0)
> On a freshly installed chroot, I found some unowned directories that IMHO
> belong to systemd :
> 
> # rpm -qf /etc/modprobe.d/
> file /etc/modprobe.d is not owned by any package

This directory should be owned by kmod, not systemd.

> # rpm -qf /etc/modprobe.d/*
> hwdata-0.242-1.fc19.noarch
> systemd-197-1.fc19.x86_64
> 
> 
> /etc/systemd/system/system-update.target.wants
> /etc/systemd/system/multi-user.target.wants
> /etc/systemd/system/default.target.wants
> /etc/systemd/system/getty.target.wants

Well, these are managed by "systemctl enable" and "systemctl disable". Correctly written package scripts will remove these on uninstall.

> /var/lib/systemd
> /var/lib/systemd/catalog
> 
> /usr/share/systemd/gatewayd

These should be fixed in systemd.

(In reply to comment #1)
> (In reply to comment #0)
> > # rpm -qf /etc/modprobe.d/
> > file /etc/modprobe.d is not owned by any package
> 
> This directory should be owned by kmod, not systemd.

I think Michael's point was that the systemd package ships the file /etc/modprobe.d/udlfb.conf, but neither does it require the package owning /etc/modprobe.d (currently 'kmod', but could be moved to 'filesystem' if it helps), nor does it co-own /etc/modprobe.d/. The guidelines require us to use one of the two options.

On the other hand, I do not know what is the baseline. I can hardly imagine a system without kmod ( maybe a container ), so this would not cause issue in practice. 

I wondered about asking to move the directory ownership to kmod-libs ( who is pulled by systemd, so this would cover all case ), but this doesn't seems right and this would break multiarch.

Does systemd use libkmod to do any loading ( and so does is take /etc/modprobe.d in account ? ), and does it require kmod to work ?

If yes, then I guess /etc/modprobe.d and friends would belong to kmod-libs.

One more directory :

$ LC_ALL=C rpm -qf /usr/include/systemd/
file /usr/include/systemd is not owned by any package

Some more dirs that should be owned by systemd, the point is the same as clarified in comment 2:

%{_sysconfdir}/X11/xorg.conf.d
%{_datadir}/polkit-1
%{_datadir}/polkit-1/actions

/usr/include/systemd, /var/lib/systemd, /var/lib/systemd/catalog, /usr/share/systemd/gatewayd are now owned by the package, in F19.

/etc/modprobe.d/udlfb.conf is gone in F19, so no need anymore to own that directory.

Leaves only:

%{_sysconfdir}/X11/xorg.conf.d
%{_datadir}/polkit-1
%{_datadir}/polkit-1/actions

And I figure that means systemd should co-own these dirs with polkit/x11.

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

systemd-204-13.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/systemd-204-13.fc19

Package systemd-204-13.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-204-13.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-16818/systemd-204-13.fc19
then log in and leave karma (feedback).

systemd-204-14.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/systemd-204-14.fc19

Hm, this has been in stable as part for a while. I guess it hasn't been marked as closed because the update was obsoleted.