Am 14.08.2012 17:15, schrieb Tom Gundersen:

On Tue, Aug 14, 2012 at 4:57 PM, Stéphane Gaudreault wrote:

...

Systemd has a overall better design than SysV, lots of useful administrative features and provide quicker boot up. Considering that it has been around in our repositories for some time and that it could be considered stable enough for production use, I would suggest to replace iniscript by systemd once the 'Missing systemd units' is over. Thus we will avoid duplicating our efforts on two init systems.

Any objections to start the migration process ?

A big +1 from me.

As to the future of initscripts: I am (as I keep saying) committed to maintaining it as long as it is part of our repos (at some point I expect it will not be any more). We'll make sure that the transition to systemd is such that initscripts can still be installed for the time being if that is desired. However, I expect that third-party packages (gnome, NetworkManager, polkit, etc.) at some point will stop working well without systemd, so that is something to consider if you stick with initscripts.

I also prefer taking the slow route here. As someone who is yet to migrate to systemd, I don't know what kind of quirks it still has. My plan: 1) Tell people to migrate to systemd. 2) Make new installations use systemd by default. 3) Stop holding back packages because of systemd. For example: polkit requires either consolekit or systemd. Drop ck support, use systemd. This means that most desktop users will need to switch to systemd - but a server that doesn't even have dbus will (for the time being) keep working with initscripts. 4) Drop initscripts as soon as udev starts breaking without systemd. I guess it will take lots of time before we do 4). Another point: Someone on the so-called "official" G+ stated: "Arch will move to systemd only boot process..." As Tom stated (and he maintains systemd and initscripts), this is not true. This angers me because 1) Something untrue and/or unprecise is being posted on the "official" G+. 2) There are claims that this G+ is official. Neither our website, nor any place else states that there is an official Arch G+ (or Facebook) page and links to it. This G+ has not been approved by developers to be "official". Yet, someone here claims to be the official G+. This must stop. If we present ourselves on social media, I want it to be approved on the private mailing list first. And if someone starts that discussion, it will get a big -1 from me.

Le 2012-08-15 12:11, Tom Gundersen a écrit :

...

My plan:

1) Tell people to migrate to systemd. 2) Make new installations use systemd by default. 3) Stop holding back packages because of systemd. For example: polkit requires either consolekit or systemd. Drop ck support, use systemd. This means that most desktop users will need to switch to systemd - but a server that doesn't even have dbus will (for the time being) keep working with initscripts. 4) Drop initscripts as soon as udev starts breaking without systemd.

I guess it will take lots of time before we do 4). I agree wholeheartedly (assuming all the needed things such as unit files are in place before we do (1), as discussed earlier in the

On Wed, Aug 15, 2012 at 5:56 PM, Thomas Bächler wrote: thread). I suppose what will trigger initscripts being dropped is people getting sick of maintaining rc scripts for our packages, which will probably happen long before udev stops working (but even that should be a long time into the future).

I agree with the proposed plan. The schedule could looks like this (1) and (2) could be done after the missing unit files rebuild is over. They should probably be announced at the same time as I expect that some users will prefer a fresh install instead of "upgrading". (3) Maybe this could be done in preparation of the gnome 3.6.0 release scheduled at the end of September. (4) There is no rush to do that, but users need to know that it _will_ happen.

Le 2012-08-15 12:46, Thomas Bächler a écrit :

Am 15.08.2012 18:41, schrieb Stéphane Gaudreault:

...

(4) There is no rush to do that, but users need to know that it _will_ happen. That is still questionable:

Assuming that udev keeps working, a server system that has no polkit (or not even dbus) installed may keep working just fine. It's just the "modern" fd.o things and desktops that start relying on systemd.

Your are right. As Tom mentionned the decision to drop the support on initscript will probably based more on the priority of work.

On Wed, Aug 15, 2012 at 12:11 PM, Tom Gundersen wrote:

On Wed, Aug 15, 2012 at 5:56 PM, Thomas Bächler wrote:

...

My plan:

1) Tell people to migrate to systemd. 2) Make new installations use systemd by default. 3) Stop holding back packages because of systemd. For example: polkit requires either consolekit or systemd. Drop ck support, use systemd. This means that most desktop users will need to switch to systemd - but a server that doesn't even have dbus will (for the time being) keep working with initscripts. 4) Drop initscripts as soon as udev starts breaking without systemd.

I guess it will take lots of time before we do 4).

I agree wholeheartedly (assuming all the needed things such as unit files are in place before we do (1), as discussed earlier in the thread). I suppose what will trigger initscripts being dropped is people getting sick of maintaining rc scripts for our packages, which will probably happen long before udev stops working (but even that should be a long time into the future).

That also looks like agood plan to me. I suppose that developpement of initscripts will stop, i.e. no more new features or bug fixes. That should gently push users to systemd and it might become the reason to remove it from the repo (step 4).

...

As Tom stated (and he maintains systemd and initscripts), this is not true. This angers me because

1) Something untrue and/or unprecise is being posted on the "official" G+.

That is indeed imprecise, but I'll admit that I didn't notice myself...

...

2) There are claims that this G+ is official. Neither our website, nor any place else states that there is an official Arch G+ (or Facebook) page and links to it. This G+ has not been approved by developers to be "official". Yet, someone here claims to be the official G+.

This must stop. If we present ourselves on social media, I want it to be approved on the private mailing list first. And if someone starts that discussion, it will get a big -1 from me.

Yeah, we should probably discuss that (though I'm personally overall happy with the G+ page).

-t

On Wednesday 15 August 2012 19:36:55 Pierre Schmitz wrote:

Yes, I see the same problem here. Due to this it's announced all over the media that we replace initscripts by systemd before it's even discussed on this list. No idea who created this, and I don't mind if there are "fanpages" on some social networks, but we should ask to remove the "official" from the title here as it is misleading and just not true.

Sorry, but what are you saying isn't true. None talked about the systemd replacement in the google+ page until that post was written and, since it links to the arch-dev-public thread, it has been written after the discussion. Just to dot your I's and cross your T's'. -- Andrea

Am 15.08.2012 20:26, schrieb Andrea Scarpino:

I don't know who write that (neither I wanna know), but you pointed out something true, so I already removed the "official" suffix from our page and "fixed" the post about systemd. I hope this is ok now.

Thank you.

On Tue, Aug 14, 2012 at 5:17 PM, Dave Reisner wrote:

A few things to encourage this which were discussed on IRC:

- merge systemd back to a single package (aside from sysvcompat) - split off some of the tools from sysvinit (pidof, last, ...)

For the future:

- drop rc.conf compat for systemd. - finish the /usr migration. Not strictly related, but this makes writing unit files easier imo. Also lets us drop a local patch against systemd.

Another big +1 from me on this too. -t

On Tuesday 14 August 2012 18:34:13 Pierre Schmitz wrote:

There are still a lot of unit files missing; we should create a todo list. It would also be helpful to write down a simple wiki page with some guidelines here.

Did I miss something or did you miss the Jan's todo list[1]?

E.g. I am not sure if we should read those /etc/conf.d/$damon files from the unit files as well or drop these as the user should override unit files in /etc.

Indeed, I was wondering if we should adapt our packages to the layout used by the upstream systemd services files. E.g. the upstream proftpd service sources /etc/system/proftpd, but our packages installs /etc/conf.d/proftpd. [1] https://www.archlinux.org/todo/178/ -- Andrea

On Tuesday 14 August 2012 12:57:37 Dave Reisner wrote:

So there is no standard for this, and the general recommendation is that if you disagree with the default command line args the service in /lib provides, you should simply override the service in /etc. If anything, I'd vote that /etc/conf.d (or whatever other name you give it) should slowly shrink/disappear over time.

Ok, so since there's no standard I'm fine with Pierre's idea to write the default parameters in the service files and drop the conf.d*whatever files. -- Andrea

On Tue, Aug 14, 2012 at 12:09:33PM -0500, Dan McGee wrote:

On Tue, Aug 14, 2012 at 11:57 AM, Dave Reisner wrote:

...

On Tue, Aug 14, 2012 at 06:39:34PM +0200, Andrea Scarpino wrote:

...

On Tuesday 14 August 2012 18:34:13 Pierre Schmitz wrote:

...

There are still a lot of unit files missing; we should create a todo list. It would also be helpful to write down a simple wiki page with some guidelines here.

Did I miss something or did you miss the Jan's todo list[1]?

...

E.g. I am not sure if we should read those /etc/conf.d/$damon files from the unit files as well or drop these as the user should override unit files in /etc.

Indeed, I was wondering if we should adapt our packages to the layout used by the upstream systemd services files. E.g. the upstream proftpd service sources /etc/system/proftpd, but our packages installs /etc/conf.d/proftpd.

So there is no standard for this, and the general recommendation is that if you disagree with the default command line args the service in /lib provides, you should simply override the service in /etc. If anything, I'd vote that /etc/conf.d (or whatever other name you give it) should slowly shrink/disappear over time.

What does the non-standard think about distro-provided updates to the units? Seems like with overriding the whole thing rather than small pieces in a separate config file, it isn't obvious to the user when they need to merge updates to the unit files.

-Dan

It's possible to include unit files (.include /lib/systemd/....), though in practice, I haven't seen how well this works.

On Tue, Aug 14, 2012 at 6:57 PM, Dave Reisner wrote:

On Tue, Aug 14, 2012 at 06:39:34PM +0200, Andrea Scarpino wrote:

...

On Tuesday 14 August 2012 18:34:13 Pierre Schmitz wrote:

...

There are still a lot of unit files missing; we should create a todo list. It would also be helpful to write down a simple wiki page with some guidelines here.

Did I miss something or did you miss the Jan's todo list[1]?

...

E.g. I am not sure if we should read those /etc/conf.d/$damon files from the unit files as well or drop these as the user should override unit files in /etc.

Indeed, I was wondering if we should adapt our packages to the layout used by the upstream systemd services files. E.g. the upstream proftpd service sources /etc/system/proftpd, but our packages installs /etc/conf.d/proftpd.

So there is no standard for this, and the general recommendation is that if you disagree with the default command line args the service in /lib provides, you should simply override the service in /etc. If anything, I'd vote that /etc/conf.d (or whatever other name you give it) should slowly shrink/disappear over time.

d

This approach would also necessitate educating our users about running systemd-delta after upgrades. Users might end up having overridden units that got updated, and as a result, break.

On 15 August 2012 07:32, Eric Bélanger wrote:

On Tue, Aug 14, 2012 at 10:57 AM, Stéphane Gaudreault wrote:

...

Systemd has a overall better design than SysV, lots of useful administrative features and provide quicker boot up. Considering that it has been around in our repositories for some time and that it could be considered stable enough for production use, I would suggest to replace iniscript by systemd once the 'Missing systemd units' is over. Thus we will avoid duplicating our efforts on two init systems.

Any objections to start the migration process ?

Cheers,

Stéphane

+1.

I don't use systemd or know how it works or compare to initscripts but I am aware that we'll need to switch to it eventually as more and more projects will depends on it. So the sooner the better.

Eric

Exactly the same position, +1. -- GPG/PGP ID: C0711BF1