= Proposal topic =
Making the description of the "systemd" feature scope more accurate and precise
= Overview =
http://fedoraproject.org/wiki/Features/systemd says the feature concerns "a replacement for !SysVinit and Upstart that acts as a system and session manager.". Reading the feature would lead one to the assumption that the only packages affected are * upstart * initscripts * daemons that support socket activation * mount/automount/autofs * readahead * and perhaps other packages, but only to switch from init.d to systemd unit files.
In fact, systemd includes, or is planned to include:
= Problem space =
The true scope of the "systemd" feature is much larger than one can assume based on the overview, or even based on careful reading of the feature page.
As a result, relevant Fedora contributors do not know they should be involved to make sure the systemd-implemented changes or replacements are adequate - or alternatively, are forced to follow systemd development closely even though it currently does not touch the area they are contributing to, because systemd may start affecting the area in near future. Both cases result in contributor frustration and wasted time.
Specific problems with specific ways systemd features are/are not implemented are not a focus of this ticket.
= Solution Overview =
In an ideal world, the full scope would have been specified in the feature page in advance.
My wish, as a second best option, is that FESCo (probably in cooperation with the owners of the systemd feature) explicitly specifies the scope of the systemd feature - i.e. affected packages or affected areas of system functionality, such that any Fedora contributor can - with trivial time investment, i.e. smaller than regularly reading systemd source code - determine if, and to what extent, the area they are focusing on is, or will be, affected by the systemd feature, and that FESCo announces the specified scope on fedora-devel.
(As a minimal test of sufficiency, the scope should include the areas mentioned in the "overview" section, and it should be more specific than "whole distribution".)
= Active Ingredients =
FESCo and systemd feature owners, for the benefit of other Fedora developers
= Owners =
?
There's no replacement for "crontabs". You can use systemd to trigger time-based events, but you don't have to. cron will continue to run by default, and is available like anything else. Maybe one day we can move handling of /etc/cron.weekly and friends to work without crond, but that's material for F16 or later, and completely open for discussion later on. But for now nothing really changes here.
systemd does not change much with the locale config, there's a fallback on how Fedora always has configured locale, and that is still used by default in F15. However, we also read a new config file that is shared among distros, if it exists (but it won't exist by default in F15). There's a single change in behaviour here really: we set the system locale in PID 1 already, so that it is inherited by all services, instead of setting it individually in all services. But that's just an improvement in correctness, not really a change in behaviour, so nothing really changes here.
The setup of temporary directories is done by the systemd-tmpfiles facility which is the replacement of the part of rc.sysinit that recreates utmp/wtmp, fixes perms, and cleans up volatile directories. This was just shifted around. And the new system is arguable cleaner and simpler and more extensible. Also, there's less chance to break things (for example, since restorecon never needs to be called explicitly and so on). tmpwatch and manual shells scripts continue to work just fine, so nothing really changes here.
And there is no way around asking for passwords using a new mechanism simply because we start things in parallel, and hence the console might be used by multiple clients at the same time. But the password query functionality is an implementation detail of cryptsetup anyway, and I see little reason to discuss this much. The only change we did her is that instead of calling the cryptsetup tool from rc.sysinit we call libcryptsetup from a systemd helper. The same code still does the work, only the password is queried a little bit differently. So nothing really changes here.
As I understand the issue raised here this is mostly about keeping people involved. We try very hard to keep people involved, and lots of people have been involved, from many distributions, not only from Fedora, and most folks involved are very happy with this, as far as I understand. Of course, sometimes we forget to ping all people with a stake in a specific topic (which happens easily if the one implementing a feature is not actually a Fedora guy, but from another distribution which is what happened regarding tmpfiles/tmpwatch), and we are sorry for that, but I don't really see any reason to make a big fuss out of this. Also, we do blog and communicate what we do pretty frequently, so if we do miss to ping somebody it shouldn't be too hard to catch up for him. Of course, we do hope that people involve themselves anyway, and if they don't they at least follow from the distance. That doesn't relieve us from pinging the right people, but otoh that we accidentaly kept one person out of the loop is a bad excuse to mix up political/social issues with technical issues, since this ticket tries to make a political point but hides behind technical issues.
In summary, I kinda hope this can be settled by us continuing to try to involve everybody who has a stake in the basic OS when we make decisions. And if we forget somebody, we try to fix that.
Mirt and Lennart will work to update the feature page to show more of the scope.
Login to comment on this ticket.