state of systemd in Fedora and services pledge

Lennart Poettering mzerqung at
Wed Feb 23 17:29:50 UTC 2011

On Wed, 23.02.11 07:04, Toshio Kuratomi (a.badger at wrote:

> > > uh... How are you creating the spec file?  In testing, I've yet to get
> > > a specfile that performs as expected.  I'd be happy if you could take
> > > a look at the proposed guidelines and figure out if this is a
> > > guidelines bug, a systemd bug, a testing bug, or a bug in the packages
> > > that I'm testing with.
> > 
> > Did you actually check if you had at least chkconfig 1.3.50-1 installed
> > when you tested this, as I wrote in the FPC bug?
> > 
> > Also, Michał's work is about adding systemd unit files, not about adding
> > SysV init scripts, because those already exist...
> > 
> Okay, I've tried all sorts of different wording to get you to understand
> what is being tested.  I'll try one more before giving up:

No. Never did. I was suggesting to ship systemd unit files and SysV
service files side by side. The current draft is tougher however, and
asks packages to remove SysV scripts if service files are around, or
split them into subpackages. That's more than what I asked for and I had
in my original draft. But of course I am happy with this too.

> Are you proposing that system V init scripts be banned for F15 and that we
> do not allow upgrades from F14 to F15, only new installs?

No. Never did.

> If you aren't proposing that, then testing that we can successfully upgrade
> from a systemVinit script using package to a systemd unit file using package
> is a test that needs to pass.

Well, I still fail to see what the packaging guidlines for systemd unit
files have to do with chkconfig, but well, maybe I am just blind.

Anyway, we don't really have to continue this discussion
here. Regardless whether chkconfig is relevant for the systemd
guidelines or not let's stay constructive: I think that the newer
chkconfig version fixes your problems, and would like to ask you to test
things with that. 

Thank you,


Lennart Poettering - Red Hat, Inc.

More information about the devel mailing list