[arch-dev-public] Switching to systemd by default in new installations
Tom and I discussed this on IRC, so I'll just throw it in here. I'd like to make the following changes to our packages: * Remove initscripts and sysvinit from the base group. * Add systemd-sysvcompat to the base group. * Move initscripts to [extra]. This effectively uses systemd by default on all new installations. As not all packages are equipped with systemd units yet, a compatibility layer exists: You can install the initscripts package, which does not depend on sysvinit any longer (and thus doesn't conflict with systemd-syscompat). A new initscripts installation will come with an empty DAEMONS array by default. Once you add rc.d scripts to DAEMONS, systemd will generate compatibility units for those services, or enable the systemd unit if a unit with the same name exists. Please discuss!
On Sun, Oct 07, 2012 at 06:49:46PM +0200, Thomas Bächler wrote:
Tom and I discussed this on IRC, so I'll just throw it in here.
I'd like to make the following changes to our packages:
* Remove initscripts and sysvinit from the base group. * Add systemd-sysvcompat to the base group.
I'd really like to get rid of the /bin/systemd symlink if we're going to do this. I suppose it can just be part of the news item we post.
* Move initscripts to [extra].
This effectively uses systemd by default on all new installations.
As not all packages are equipped with systemd units yet, a compatibility layer exists: You can install the initscripts package, which does not depend on sysvinit any longer (and thus doesn't conflict with systemd-syscompat). A new initscripts installation will come with an empty DAEMONS array by default. Once you add rc.d scripts to DAEMONS, systemd will generate compatibility units for those services, or enable the systemd unit if a unit with the same name exists.
This "compatability" layer is still a mess with packages shipping rc.d files which don't match up with the unit file name. I proposed a solution for this in initscripts that involved keeping a static list of exceptions in arch-daemons rather than peppering packages with symlinks full of lies, and it appears that nothing has been done yet. This _must_ to be fixed first.
Please discuss!
Am 07.10.2012 19:29, schrieb Dave Reisner:
On Sun, Oct 07, 2012 at 06:49:46PM +0200, Thomas Bächler wrote:
Tom and I discussed this on IRC, so I'll just throw it in here.
I'd like to make the following changes to our packages:
* Remove initscripts and sysvinit from the base group. * Add systemd-sysvcompat to the base group.
I'd really like to get rid of the /bin/systemd symlink if we're going to do this. I suppose it can just be part of the news item we post.
Why did you even introduce this symlink in the first place? Why did you not remove this symlink _before_ we told everyone to use init=/bin/systemd on their command line? If you knew this symlink was going to disappear eventually, why not tell everyone to use init=/usr/lib/systemd/systemd from the beginning? (Not trying to be rude, I really need a history lesson on this.)
As not all packages are equipped with systemd units yet, a compatibility layer exists: You can install the initscripts package, which does not depend on sysvinit any longer (and thus doesn't conflict with systemd-syscompat). A new initscripts installation will come with an empty DAEMONS array by default. Once you add rc.d scripts to DAEMONS, systemd will generate compatibility units for those services, or enable the systemd unit if a unit with the same name exists.
This "compatability" layer is still a mess with packages shipping rc.d files which don't match up with the unit file name. I proposed a solution for this in initscripts that involved keeping a static list of exceptions in arch-daemons rather than peppering packages with symlinks full of lies, and it appears that nothing has been done yet. This _must_ to be fixed first.
In the current status, only a small number of people will even need it, and they will only specify services which do not have a unit at all - and nothing is broken there. I don't really see the problem - can't we expect our users to gradually remove the compatibility DAEMONS over time? Do we really have to hold their hands? Can you give a link to your proposed patches? I am really not against improving this, I just don't see it as a showstopper.
On Sun, Oct 07, 2012 at 07:43:13PM +0200, Thomas Bächler wrote:
Am 07.10.2012 19:29, schrieb Dave Reisner:
On Sun, Oct 07, 2012 at 06:49:46PM +0200, Thomas Bächler wrote:
Tom and I discussed this on IRC, so I'll just throw it in here.
I'd like to make the following changes to our packages:
* Remove initscripts and sysvinit from the base group. * Add systemd-sysvcompat to the base group.
I'd really like to get rid of the /bin/systemd symlink if we're going to do this. I suppose it can just be part of the news item we post.
Why did you even introduce this symlink in the first place? Why did you not remove this symlink _before_ we told everyone to use init=/bin/systemd on their command line? If you knew this symlink was going to disappear eventually, why not tell everyone to use init=/usr/lib/systemd/systemd from the beginning? (Not trying to be rude, I really need a history lesson on this.)
Once upon a time, systemd was installed to /bin, and we told people to use init=/bin/systemd. It seemed like the logical thing to do ;). This entirely predates the /usr merge and we had no idea that the binary was going to move to {,/usr}/lib. We had no idea this was coming, but I've opposed to getting rid of it because it doesn't cost us a whole lot. I think this is an excellent time to remove it.
As not all packages are equipped with systemd units yet, a compatibility layer exists: You can install the initscripts package, which does not depend on sysvinit any longer (and thus doesn't conflict with systemd-syscompat). A new initscripts installation will come with an empty DAEMONS array by default. Once you add rc.d scripts to DAEMONS, systemd will generate compatibility units for those services, or enable the systemd unit if a unit with the same name exists.
This "compatability" layer is still a mess with packages shipping rc.d files which don't match up with the unit file name. I proposed a solution for this in initscripts that involved keeping a static list of exceptions in arch-daemons rather than peppering packages with symlinks full of lies, and it appears that nothing has been done yet. This _must_ to be fixed first.
In the current status, only a small number of people will even need it, and they will only specify services which do not have a unit at all - and nothing is broken there. I don't really see the problem - can't we expect our users to gradually remove the compatibility DAEMONS over time? Do we really have to hold their hands?
Apparently we do. I've been against the generator from the start. Force things to break, and let people who actually care fix them. At a minimum, we realy need to get rid of the broken symlinks that we're shipping. You can start/stop/status them by the symlink name, but you can't enable them, and the message is totally non-descript.
Can you give a link to your proposed patches? I am really not against improving this, I just don't see it as a showstopper.
I never wrote the patch, but maybe I need to if no one else is going to do it. I can probably find 10 minutes this afternoon to write an RFC patch. d
On Sun, Oct 7, 2012 at 7:54 PM, Dave Reisner <d@falconindy.com> wrote:
Once upon a time, systemd was installed to /bin, and we told people to use init=/bin/systemd. It seemed like the logical thing to do ;). This entirely predates the /usr merge and we had no idea that the binary was going to move to {,/usr}/lib. We had no idea this was coming, but I've opposed to getting rid of it because it doesn't cost us a whole lot. I think this is an excellent time to remove it.
Maybe even better would be to do this once everyone has been using systemd-sysvcompat for a long time, and the advice about using init=/bin/systemd is long forgotten. I don't see the rush to remove the symlink, it will very likely cause boot problems for lots of people.
This "compatability" layer is still a mess with packages shipping rc.d files which don't match up with the unit file name. I proposed a solution for this in initscripts that involved keeping a static list of exceptions in arch-daemons rather than peppering packages with symlinks full of lies, and it appears that nothing has been done yet. This _must_ to be fixed first.
In the current status, only a small number of people will even need it, and they will only specify services which do not have a unit at all - and nothing is broken there. I don't really see the problem - can't we expect our users to gradually remove the compatibility DAEMONS over time? Do we really have to hold their hands?
Apparently we do. I've been against the generator from the start. Force things to break, and let people who actually care fix them. At a minimum, we realy need to get rid of the broken symlinks that we're shipping. You can start/stop/status them by the symlink name, but you can't enable them, and the message is totally non-descript.
I'm not a huge fan of just letting lots of stuff break. However, I agree that the symlink situation is unacceptable and I think the best solution would be to just remove all the symlinks and tell people to only put stuff in DAEMONS that don't have systemd services. At worst this might mean that some things are started twice, probably one of the two instances will fail and with the right advice in a news item I don't think it is too much too expect our users to figure out that they just need to remove the relevant DAEMONS from rc.conf. -t
On Sun, Oct 7, 2012 at 9:12 PM, Tom Gundersen <teg@jklm.no> wrote:
I agree that the symlink situation is unacceptable and I think the best solution would be to just remove all the symlinks and tell people to only put stuff in DAEMONS that don't have systemd services.
At worst this might mean that some things are started twice, probably one of the two instances will fail and with the right advice in a news item I don't think it is too much too expect our users to figure out that they just need to remove the relevant DAEMONS from rc.conf.
I updated initscripts in testing to what I think is an acceptable state and removed it from base. Notice that this does not address Dave's concern, but assumes that we will just remove the symlinks we have put in networkmanager++ before this goes to [extra]. We'd also need to actually add systemd-sysvcompat to base before making the move. Comments? -t
participants (3)
-
Dave Reisner
-
Thomas Bächler
-
Tom Gundersen