Many packages have no real dependency on systemd, but include .service files. This makes packaging for application dependencies difficult — either directory ownership is ignored (messy, guidelines violation) or else systemd is pulled in (bloat in a minimal application container). This kind of thing is what the filesystem package is basically for, so it seems like a good solution.
Yes, I thought so as well (I already replied in the thread proposing this ownership - https://lists.fedoraproject.org/pipermail/devel/2014-October/203376.html ), however Zbigniew from systemd doesn't think this is really important - as the packages with unitfiles will still require systemd macros ( https://lists.fedoraproject.org/pipermail/devel/2014-October/203379.html ). I agree filesystem package serves for these purposes, however if there is no benefit (and the requirements are still there because of the systemd macros), we should probably keep it in systemd. Adding Zbigniew and Lukas from systemd maintainers so they can comment on it.
If packages ships a unit file, than it needs to use those macros, otherwise we will not benefit from the systemd preset policy. And all of this is specified in our package guidelines.
Ok, looking at https://fedoraproject.org/wiki/Packaging:Systemd, BuildRequires are sufficient to get the macros available, right? If I move the unitdir directory into filesystem package, will it solve the dependencies and fakesystemd troubles within images?
No, those macros run actual systemd commands.
Discussed further with Lukas Nykryn and with current packaging guidelines, it brings no benefit for anyone (and brings potential breakage). I'm sorry, but closing WONTFIX for now - feel free to reopen, once there are packaging guidelines changes for containers and clear benefit from this change.
(In reply to Lukáš Nykrýn from comment #2) > If packages ships a unit file, than it needs to use those macros, otherwise > we will not benefit from the systemd preset policy. And all of this is > specified in our package guidelines. The preset policy was designed for traditional systems, not for containers. If I'm building a Docker container that just has apache, I actually *don't* want anything else enabled by default. And it's quite easy to just turn on httpd.
> The preset policy was designed for traditional systems, not for containers. > If I'm building a Docker container that just has apache, I actually *don't* > want anything else enabled by default. And it's quite easy to just turn on > httpd. Than you can provide your own preset file. But seriously, I completely understand what you want to achieve and it could be a valid use-case. But this has to go through FPC, base working group,... and we should not deal with it under filesystem bugzilla.