Description of problem: Let's get the ball rolling on this one... http://fedoraproject.org/wiki/Features/SysVtoSystemd https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 561208 [details] Native systemd service for iondine client
Created attachment 561209 [details] Native systemd service for iondine server
SysV script got settings from /etc/sysconfig/iodine-{cleint,server} files. You provide very simple systemd services with hardcoded parameters. How it intended to be customized?
(In reply to comment #3) > SysV script got settings from /etc/sysconfig/iodine-{cleint,server} files. You > provide very simple systemd services with hardcoded parameters. How it intended > to be customized? /etc/sysconfig/foo Environment files are in a sense obsolete and Fedora/Red Hat distribution specific thus wont fly with upstream when you submit the units there. The future and distribution agnostic way to customize units for daemons that do not support parsing a config file is this. http://fedoraproject.org/wiki/Systemd#How_do_I_customize_a_unit_file.2F_add_a_custom_unit_file.3F
(In reply to comment #4) > (In reply to comment #3) > /etc/sysconfig/foo Environment files are in a sense obsolete and Fedora/Red Hat > distribution specific thus wont fly with upstream when you submit the units > there. IIRC Systemd also used only in Fedora now, so it is Fedora specific and for what it for upstream author I couldn't understand. > The future and distribution agnostic way to customize units for daemons that do > not support parsing a config file is this. Iodine does not use any config AFAIK. So, should I treat systemd units as config files and provide your units do not wait it may be started without modifications by users??
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > /etc/sysconfig/foo Environment files are in a sense obsolete and Fedora/Red Hat > > distribution specific thus wont fly with upstream when you submit the units > > there. > IIRC Systemd also used only in Fedora now, so it is Fedora specific and for > what it for upstream author I couldn't understand. Who feed you that information that systemd was only in Fedora? That individual needs to be corrected. You can enlighten his ignorance and just point him to http://cgit.freedesktop.org/systemd/systemd/tree/configure.ac and read line 419 ( case $with_distro in ) and higher which contains a list of distribution that either currently are shipping systemd as a default or they are shipping it along their current implementation as an alternative or are working on shipping systemd. > > > The future and distribution agnostic way to customize units for daemons that do > > not support parsing a config file is this. > Iodine does not use any config AFAIK. So, should I treat systemd units as > config files and provide your units do not wait it may be started without > modifications by users?? Sorry not following you here. Ship the units. drop the /etc/sysconfig/foo files and point users to use http://fedoraproject.org/wiki/Systemd#How_do_I_customize_a_unit_file.2F_add_a_custom_unit_file.3F instead.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > (In reply to comment #3) > > > /etc/sysconfig/foo Environment files are in a sense obsolete and Fedora/Red Hat > > > distribution specific thus wont fly with upstream when you submit the units > > > there. > > IIRC Systemd also used only in Fedora now, so it is Fedora specific and for > > what it for upstream author I couldn't understand. > > Who feed you that information that systemd was only in Fedora? > > That individual needs to be corrected. > > You can enlighten his ignorance and just point him to > http://cgit.freedesktop.org/systemd/systemd/tree/configure.ac and read line 419 > ( > case $with_distro in ) and higher which contains a list of distribution that > either currently are shipping systemd as a default or they are shipping it > along their current implementation as an alternative or are working on shipping > systemd. No. It is just list of sustems on which it may be configured and built (configure script support it). Nothing more! According to Ubuntu WIKI f.e. ( https://wiki.ubuntu.com/systemd#Warning.21_Experimental_code ) it is experimental code (on Jan 2012) and does not supported. > > > > > The future and distribution agnostic way to customize units for daemons that do > > > not support parsing a config file is this. > > Iodine does not use any config AFAIK. So, should I treat systemd units as > > config files and provide your units do not wait it may be started without > > modifications by users?? > > Sorry not following you here. > > Ship the units. drop the /etc/sysconfig/foo files and point users to use > http://fedoraproject.org/wiki/Systemd#How_do_I_customize_a_unit_file.2F_add_a_custom_unit_file.3F > instead. Ok. Thanks for files, I'll integrate them in near days.
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > (In reply to comment #4) > > > > (In reply to comment #3) > No. It is just list of sustems on which it may be configured and built > (configure script support it). Nothing more! > > According to Ubuntu WIKI f.e. ( > https://wiki.ubuntu.com/systemd#Warning.21_Experimental_code ) it is > experimental code (on Jan 2012) and does not supported. First of all people in those distributions are the ones that add those configuration or ask for it's inclusions by submitting patches. Distribution specific code in systemd is generally frown upon and will be removed in the future. Secondly Opensuse already has switched to systemd mageia will make the switch in their next release, gentoo and arch have supported it as an alternative for quite sometime now, Debian last time I check was debating if they should support three init systems I say have at it. Ubuntu develops and uses upstart and frankly nobody gives a flying .... what they do. They have already started to fork themselves in the corner. And several embedded distro already are using systemd.
Please check that scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=3812716
Pavel, do you intend to commit this, or should I go ahead? I can modify the unit file to source /etc/sysconfig/foo.
(In reply to comment #10) > Pavel, do you intend to commit this Off course. I had wait answer from someone (Jóhann B. Guðmundsson preferably) who test it. It commited and built now http://koji.fedoraproject.org/koji/taskinfo?taskID=4013169 >, or should I go ahead? I can modify the unit file to source /etc/sysconfig/foo. I think it have no worth.
iodine-0.6.0-0.rc1.9.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/iodine-0.6.0-0.rc1.9.fc16
iodine-0.6.0-0.rc1.9.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/iodine-0.6.0-0.rc1.9.fc17
Got it. Thanks!
Package iodine-0.6.0-0.rc1.9.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing iodine-0.6.0-0.rc1.9.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-6433/iodine-0.6.0-0.rc1.9.fc17 then log in and leave karma (feedback).
iodine-0.6.0-0.rc1.9.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
iodine-0.6.0-0.rc1.9.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.