We have assorted init scripts that have historically defined custom actions.
Given that this is an unbounded set, it is impossible to handle them
natively in systemd. However, they're usually part of administrators muscle
Better late than never (and thanks to Michal Schmidt), I've added support to
/sbin/service for running legacy actions if specified.
HOW TO IMPLEMENT IN YOUR PACKAGE
For each legacy option (such as "xyzzy") supported by your init script (such
as "frobozz"), package an executable script named:
If this file exists and is executable, then when an administrator runs:
/sbin/service frobozz xyzzy
this file will be executed, to do whatever. This file can be a symlink
somewhere else, or even a compiled executable if you really desire.
1) A legacy action of this sort should print to stderr the preferred way to
accomplish the task, if one is supported.
2) Don't package a legacy action for new scripts or actions that were not
supported by the prior init script; this is intended for compatibility with
existing scripts and/or administrator brains.
3) Don't package
or we will hurt you. (And /sbin/service will likely be changed to ignore
these actions if this becomes a problem.)
WHEN THIS WILL LAND
It's in initscripts git now, will package shortly for F18/F17/F16.
We're hosting a systemd and journal sprint the week of September 3-7, 2012 at
Pantheon Headquarters in downtown San Francisco.
Registration is on EventBrite and open now:
A bunch of proposed projects from me and other members of the systemd
development list are on the EventBrite page.
Come one day, come the whole week, or just register to participate
online. There is a donation option that will go to the Open Source
If you need travel or lodging assistance, please email me. I'll try to
work with anyone who has a demonstrated history of contributions to
FOSS projects -- even if it's not systemd. If we get a few people
seeking lodging, I might book a hack house with a few bedrooms on
| +1 512 577 5827 [mobile]
I'm still looking for someone to review my Python package (
https://bugzilla.redhat.com/show_bug.cgi?id=823679 ), and then hopefully
sponsor me as a packager- if anyone would be interested in doing either
that would be greatly appreciated, and I'd try to review one of your
packages in turn (and I would be able to do so formally after sponsorship).
But, the actual point of this message is simply to ask: is it okay for me
to submit additional packages for review while still awaiting sponsorship?
I would assume it is, but I just wanted to make sure before I actually do
I'm a long time user and first time contributor to Fedora. I think it's
about time I started giving back!
Currently, I work as an engineer for Eucalyptus Systems and I write code in
bash, python, perl, and C++.
I've submitted my first package review which you can view here:
My Freenode IRC nick: mspaulding
My FAS Username: madsa
This is about a package BZ #787713. It's standard, C++ library with a
base and -devel package.
The devel package contains both arch-dependent stuff (*.so) and noarch
Now, Ralf Corsepius raised the issue that package-devel.i386 and
package-devel.x86_64 cant be installed in parallell: they will conflict
e. g. , on the headers which are the same in both packages.
Basically, Ralf is right. An obvious solution might be to separate the
noarch headers and arch-dependent files into separate packages like
-devel and -devel-noarch.
It's just that I don recognize this. How should Ralf's vary valid remark
be handled? Seems that this should occur with a lot of -devel packages?