Bug 789767 - Provide native systemd service
Summary: Provide native systemd service
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: mediatomb
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Rich Mattes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 751869
TreeView+ depends on / blocked
 
Reported: 2012-02-12 21:54 UTC by Jóhann B. Guðmundsson
Modified: 2012-07-07 14:43 UTC (History)
4 users (show)

Fixed In Version: mediatomb-0.12.1-16.fc17
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-06 20:46:28 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Native systemd service for mediatomb (406 bytes, text/plain)
2012-02-12 21:55 UTC, Jóhann B. Guðmundsson
no flags Details

Description Jóhann B. Guðmundsson 2012-02-12 21:54:48 UTC
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:

Comment 1 Jóhann B. Guðmundsson 2012-02-12 21:55:20 UTC
Created attachment 561309 [details]
Native systemd service for mediatomb

Comment 2 Gwyn Ciesla 2012-02-14 17:05:56 UTC
Rich, any objection to my making this change?

Comment 3 Rich Mattes 2012-02-14 18:27:32 UTC
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 :)

Comment 4 Gwyn Ciesla 2012-02-14 18:35:39 UTC
Cool, will do.

Comment 5 Gwyn Ciesla 2012-02-15 19:43:06 UTC
Done, thanks all!

Comment 6 Jóhann B. Guðmundsson 2012-02-15 19:54:21 UTC
Any particular reason why you are building things only on rawhide?

Comment 7 Gwyn Ciesla 2012-02-15 19:58:13 UTC
Bodhi is now in place for f17, so they would be updates.  Which means the systemd change would happen after upgrade time.

Comment 8 Jóhann B. Guðmundsson 2012-02-15 20:07:58 UTC
Sorry not following? 

It's more important to get this in F17 than F18 at this time

Comment 9 Gwyn Ciesla 2012-02-15 20:22:41 UTC
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

Comment 10 Jóhann B. Guðmundsson 2012-02-15 20:40:01 UTC
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...

Comment 11 Gwyn Ciesla 2012-02-15 20:44:28 UTC
CCing Spot.  Spot, when you were doing systemd updates, did you do freeze exceptions or just Bodhi updates?

Comment 12 Rich Mattes 2012-02-27 21:07:31 UTC
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

Comment 13 Gwyn Ciesla 2012-02-27 21:15:49 UTC
Go for it. :)

Comment 14 Fedora Update System 2012-02-27 23:08:08 UTC
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

Comment 15 Fedora Update System 2012-02-28 20:40:13 UTC
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).

Comment 16 Fedora Update System 2012-03-06 20:46:28 UTC
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.

Comment 17 Ian Chapman 2012-07-04 09:52:58 UTC
Is hardcoding the interface, port etc into the systemd service file considered migrating the service to systemd? Is that good practice?

Comment 18 Jóhann B. Guðmundsson 2012-07-04 11:40:55 UTC
(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

Comment 19 Ian Chapman 2012-07-06 14:25:26 UTC
(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?

Comment 20 Gwyn Ciesla 2012-07-06 14:35:27 UTC
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.

Comment 21 Ian Chapman 2012-07-06 14:54:54 UTC
(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.

Comment 22 Gwyn Ciesla 2012-07-06 15:10:08 UTC
I've picked it up.  You might want to just add your concerns to 

https://bugzilla.redhat.com/show_bug.cgi?id=826377

Comment 23 Ian Chapman 2012-07-06 15:26:06 UTC
(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.

Comment 24 Jóhann B. Guðmundsson 2012-07-06 15:42:41 UTC
(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

Comment 25 Rich Mattes 2012-07-07 14:43:27 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.