[HEADS-UP] systemd for F14 - the next steps
crobinso at redhat.com
Fri Jul 23 16:43:55 UTC 2010
On 07/22/2010 07:16 PM, Lennart Poettering wrote:
> On Fri, 23.07.10 00:55, Rahul Sundaram (metherid at gmail.com) wrote:
>> On 07/23/2010 12:10 AM, Lennart Poettering wrote:
>>> Kay and I have discussed this now. We agreed to fold systemd-install
>>> into systemctl entirely, and replace --realize by --now. Also, we'll
>>> drop some of the options --realize had, and always imply that the init
>>> system configuration shall be reloaded after all changes took
>>> place. This basically means that this
>>> is what will be done in %post in the general case:
>>> if [ $1 -eq 1 ] ; then
>>> systemctl enable foo.service
>>> systemctl daemon-reload
>> Is there a particular reason why systemctl enable foo shouldn't work?
>> why am I specifying foo.service there?
> Well, because you mean the service, not the socket or the timer or any
> other kind of unit?
It would be nice if systemctl enable foo implies foo.service, presumably
services are going to be the most common unit type manipulated with
systemctl, and it's closer to service/chkconfig behavior.
Coupled with a clear error message like 'No unit file found
/etc/systemd/foo.blah', there wouldn't be any user confusion if someone
tries systemctl enable foo for foo.socket.
More information about the devel