Dne 26.8.2014 19:12, Orion Poplawski napsal(a):
> On 08/26/2014 04:59 AM, Vít Ondruch wrote:
>> Dne 26.8.2014 11:06, Michal Sekletar napsal(a):
>>> On Tue, Aug 26, 2014 at 09:32:26AM +0200, Vít Ondruch wrote:
>>>> Hi,
>>> Hi Vít,
>>>
>>>> Recently I have noticed that systemd package dependency is creeping
>>>> into
>>>> some packages where it is not necessary. subversion [1] or rsync
>>>> [2] are
>>>> good examples. Please consider moving daemon parts into independent
>>>> subpackages. When I install rsync/subversion, I am typically
>>>> interested
>>>> just in client side.
>>> At some point in time (F16 IIRC) we had systemd-units package which
>>> contained
>>> /etc/rpm/macros.systemd file. Packagers which followed our
>>> guidelines used for
>>> example %{unitdir} macro in %files. Hence they added systemd-units to
>>> BuildRequires.
>>>
>>> These days systemd-units no longer exists, macro file moved to
>>> systemd rpm and
>>> systemd-units is a provided by systemd rpm.
>>
>> Thank you for insightful explanation.
>>
>> Nevertheless, if you are using some macro, it is just build time
>> dependency. I believe that the issue might be due to %{unitdir} folder
>> ownership. And I see two solutions:
>>
>> 1) Packages which ships unit files should consider to put them into sub
>> package called either -daemon or -server. And this applies especially to
>> packages such as man (forgot to mention this one previously), rsync or
>> subversion. I don't typically use their server features or con jobs or
>> whatever.
>
> Looks like rsync now has a -daemon sub-package, as you requested, and
> which I think is a good thing.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1123813
>
> Wish it went with a -server name, as that seems much more common,
> especially for admin configurable services. Really wish we had more
> standardized names.
>
> [root@vmrawhide ~]# yum list \*-server | wc -l
> 137
> [root@vmrawhide ~]# yum list \*-daemon | wc -l
> 30
>
>
This was partially call for that standardization, although not explicit ;)
Vít
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
