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 561309 [details] Native systemd service for mediatomb
Rich, any objection to my making this change?
No, i don't have any objection. The service file looks good, I've just been trying to make sense of which scriptlets I need to put in for the transition so I don't screw it up. If you want to handle putting it in you are certainly more than welcome to :)
Cool, will do.
Done, thanks all!
Any particular reason why you are building things only on rawhide?
Bodhi is now in place for f17, so they would be updates. Which means the systemd change would happen after upgrade time.
Sorry not following? It's more important to get this in F17 than F18 at this time
It has to go in f18 regardless. f17 was branched 2/6, if I recall correctly. This moved rawhide to f18. Up until a certain point, builds for f17 flowed directly into f17, just like how builds for master flow directly into rawhide. However, as of yesterday, they flipped the switch to freeze f17, meaning that for any f17 build to get pushed out, a Bodhi update has to be submitted. What this means is that let's say a user has mediatomb installed on f16. It uses sysvinit. Then she upgrades to f17. mediatomb on her f17 machine still uses sysvinit. Then she runs yum and grabs all her updates. Now she gets the mediatomb update that switches to systemd. She expected all her services to stay on one init system or the other, except at release upgrade time, and now she's had one change in the middle of a release. How, exceptions can be made, but I feel like these should be left up to the individual maintainers. https://fedoraproject.org/wiki/Branch_Freeze_Policy
Tom ( spot ) pushed systemd units into the F16 all the way up to beta ( actually two weeks over to ensure that units would find it's way into F16 ) It's more important to have the units as soon as possible into the F17 release than having them in F18. +We did not care then for users that "upgraded" to the F16 release dont see why we should care now...
CCing Spot. Spot, when you were doing systemd updates, did you do freeze exceptions or just Bodhi updates?
Re-opening to address the f17 question. It looks like FESCo has clarified that f17 packages are still allowed to transition to systemd up until beta[1]. Does that answer the above questions, and allow us to cherry-pick the systemd changes from rawhide back to the f17 branch? I'm ok with doing so, and will go ahead with it unless there's reason not to. [1] http://lists.fedoraproject.org/pipermail/devel/2012-February/163216.html
Go for it. :)
mediatomb-0.12.1-16.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/mediatomb-0.12.1-16.fc17
Package mediatomb-0.12.1-16.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 mediatomb-0.12.1-16.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-2615/mediatomb-0.12.1-16.fc17 then log in and leave karma (feedback).
mediatomb-0.12.1-16.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
Is hardcoding the interface, port etc into the systemd service file considered migrating the service to systemd? Is that good practice?
(In reply to comment #17) > Is hardcoding the interface, port etc into the systemd service file > considered migrating the service to systemd? Migrating the legacy sysv init script yes > Is that good practice? Dependes on what you mean by that. In a perfect pony world all daemon would read and use configuration file at startup if applicable etc but feel free to probarly patch mediatomb to daemon startup on the 21 century
(In reply to comment #18) > (In reply to comment #17) > > Is hardcoding the interface, port etc into the systemd service file > > considered migrating the service to systemd? > > Migrating the legacy sysv init script yes The legacy init script didn't hard code the values. It sourced a configuration file which is still distributed in the RPM. Is that not possible with the 21st century systemd? Or is it expected that the service file is copied to /etc/systemd/system then edited?
systemd is capable of sourcing /etc/sysconfig/foo files, but you'll get varying opinions on this practice. I'm of the opinion that if your package has been using a sysconfig file and still needs to with systemd, then that's fine, but not to start using one if you haven't previously. Others feel that sysconfig files should never be used.
(In reply to comment #20) > systemd is capable of sourcing /etc/sysconfig/foo files, but you'll get > varying opinions on this practice. I'm of the opinion that if your package > has been using a sysconfig file and still needs to with systemd, then that's > fine, but not to start using one if you haven't previously. Others feel > that sysconfig files should never be used. Thanks Jon, that adds some clarification. The file /etc/mediatomb.conf was sourced by the init script so it probably *should* have been /etc/sysconfig/mediatomb originally. However that file appears to be entirely redundant and misleading in the current release. Unfortunately mediatomb appears to be orphaned now but I will look posting some fixes in case it's ever picked up again, if nothing else I'll maintain a private rpm I'll still need it in the future even if it's purged from Fedora.
I've picked it up. You might want to just add your concerns to https://bugzilla.redhat.com/show_bug.cgi?id=826377
(In reply to comment #22) > I've picked it up. You might want to just add your concerns to > > https://bugzilla.redhat.com/show_bug.cgi?id=826377 Thanks. That bug pretty much somes it up.
(In reply to comment #20) > systemd is capable of sourcing /etc/sysconfig/foo files, but you'll get > varying opinions on this practice. I'm of the opinion that if your package > has been using a sysconfig file and still needs to with systemd, then that's > fine, but not to start using one if you haven't previously. Others feel > that sysconfig files should never be used. Various upstreams rejects systemd unit files that contain distribution spesific bits that are stored under /etc/sysconfig/foo ( Fedora/RHEL ) or /etc/defaults/foo ( debian ). Safe place to source files from units is either directly from the /etc directory as in /etc/foo or from a directory relevant to the component as in /etc/bla.d/file thus the unit will be distribution agnostic and acceptable by various upstreams. Sourcing /etc/sysconfig/foo files should be deprecated within the project but worry not since that's not going to happen within the project atleast not until RHEL is out the door since it might affect/uppset the RHEL customare base and those Red Hat employees in FESCO will make sure that will not happen otherwise that would have accepted my cleanup feature which amongst other things did do just that... More about this topic can be found here [1] http://www.google.is/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CE4QFjAA&url=http%3A%2F%2F0pointer.de%2Fblog%2Fprojects%2Fon-etc-sysinit.html&ei=4QX3T4iCFJSw8QOdy8mCBw&usg=AFQjCNFiSSVVTD7bC8y5S--fBwbfF6vOVw
FWIW, mediatomb doesn't seem to have any upstream anymore. Changes like conversion to js 1.8 and systemd are going to have to be carried by all of the distributions that choose to continue to support mediatomb, unless someone else steps in and takes over/forks the project.