Heads Up: FESCo is considering to block packages providing sysvinit services without systemd unit

Ian Kent raven at themaw.net
Wed Nov 9 05:49:30 UTC 2011


On Tue, 2011-11-08 at 13:52 +0100, Tomasz Torcz wrote:
> On Tue, Nov 08, 2011 at 01:41:28PM +0100, drago01 wrote:
> > On Mon, Nov 7, 2011 at 8:28 PM, Tomas Mraz <tmraz at redhat.com> wrote:
> > > On the today's FESCo meeting we discussed the request to move forward
> > > the conversion of the sysvinit scripts to systemd units in Fedora 17.
> > >
> > > The packages which ship sysvinit script but do not ship systemd unit
> > > according to the Fedora packaging guidelines violate this rule:
> > > https://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files
> > >
> > Such a blocking would be just wrong ... as long as the packages *work*
> > there is no reason to do that.
> > I am all for encouraging maintainers to port there stuff but this is a
> > bit too much.
> 
>   What other form of encouragement can you suggest?

This email thread for a start.

I'm not hurrying to make changes to my package because I've had problems
a couple of times now because of what I consider poor documentation or a
lack of information about where to find documentation. This isn't
specific to systemd at all.

Recent bugs relating to startup problems haven't been worked on because
of ongoing confusion over other init mechanisms and the lack of
assistance in terms of adequate documentation, at least as far as what I
was pointed to.

The documentation link in this thread however is somewhat more useful
but that implies that there is a huge amount of work to do on my daemon
and that will take time. Assuming I do get a pointer to adequate
documentation to unit file construction I'll then start on daemon work.

But don't forget, this is not high priority because the daemon itself
does work OK, except for the startup order dependency difficulties that
have arisen, which weren't introduced by me.

So, to sum up, this thread has encouraged me to look further into
systemd support and a heavy handed approach will not make that go any
faster.

Ian





More information about the devel mailing list