On Mon, Aug 27, 2012 at 08:24:21AM +0200, Sven-Hendrik Haase wrote:

Heiko Baums wrote:

Am Sun, 26 Aug 2012 17:15:39 -0400 schrieb Dave Reisner :

...

I apologize for this being somewhat after-the-fact. It was discussed on IRC, but that of course doesn't necessarily cater to a wide enough audience. Some of you have probably already noticed that systemd 189 now provides, conflicts, and replaces libsystemd and systemd-tools. This is the next logical step since systemd will eventually be in base once we have sufficient unit coverage.

As an added bonus, maybe this will encourage people who haven't switched over yet to do so. ;)

"Nobody is forcing systemd on anybody."

Wasn't it this what was always said by the devs in all those long threads about systemd? And what are you doing now? Isn't this not forcing it on everybody?

"Nobody has the intention to build a wall."

Heiko

Up till now you didn't have a choice, you had to use initscripts and you liked it. Why don't you take over maintenance of them so people can keep using them? Systemd and sysvinit aren't the only inits out there, there is runit, upstart, openrc all of which are available in the aur

http://en.wikipedia.org/wiki/Init -- Daniel Wallace Archlinux Trusted User (gtmanfred) Georgia Institute of Technology

On Mon, 27 Aug 2012 09:48:48 +0200 Tom Gundersen wrote:

Since the above quoted statement was made, a decision was taken to move to systemd by default, so it clearly no longer applies. While you are still free to use initscripts, at some point other packages are likely to depend on you booting with systemd (NetworkManager, polkit, Gnome, etc.).

Please support our traditional initscripts as long as possible, as I for one really don't look forwards to systemd, at least not at this point in time. Reasons excluded to avoid yet another flamefest...:(

On 27 August 2012 10:40, Tom Gundersen wrote:

On Aug 27, 2012 10:32 AM, "Joakim Hernberg" wrote:

...

Please support our traditional initscripts as long as possible,

I will. I just don't know how long that will be, so people should prepare to move.

Tom

I can help (or at least try to) with support for initscripts if it's going to be a burden for you some day in the future. I won't give up using initscripts on my desktop so easily ;-). Lukas

The 27/08/12, Tom Gundersen wrote:

As has been mentioned, the problems I foresee are (ordered from "currently a problem" to "a potential problem a long time from now":

1) not enough people testing initscripts. This would be easy to help out with :-) 2) third-party software (such as gnome/polkit/...) getting hard dependencies on booting with systemd (essentially everything that now depends on consolekit, and maybe more). If you don't use the affected software this does not matter, if you do it is not really easy to work around. 3) devs at some point no longer wanting to maintain the various rc scripts. If people are committed enough I guess an "rc scripts" package could be put in the AUR to deal with this case (if ever it becomes a problem, which it might not).

Notice that debian is working on a tool to automagically convert unit systemd files into initscripts. https://github.com/akhilvij/systemd-to-sysvinit-converter Might be worth giving it a try and contribute to get easier support of sysvinit in the long term. -- Nicolas Sebrecht

Op 28 aug. 2012 10:06 schreef "Tom Gundersen" het volgende:

On Tue, Aug 28, 2012 at 8:57 AM, Nicolas Sebrecht

wrote:

...

Notice that debian is working on a tool to automagically convert unit systemd files into initscripts.

https://github.com/akhilvij/systemd-to-sysvinit-converter

If that works, it would be great. However, I'm very skeptical. I don't see how this could possibly work for services of type other than "forking" (i.e., how to simulate socket/dbus activation). As we hope that as few services as possible will be using Type=forking, that is a problem. Having had a brief look through the code/documents I see no mention of this issue, but maybe I'm missing something obvious...

Actually, that sounds like a fairly small issue... With most daemons i prefer to either start them at boot or not at all. In case any daemon requires socket activation, you can use xinetd for those. mvg, Guus

The 28/08/12, Tom Gundersen wrote:

I guess what I wrote was a bit misleading. Ignore socket/dbus activation (that is a side effect only). The point is that I don't see how to make daemons of Type=simple (the default), Type=dbus or Type=notify work without reimplementing much of systemd (regardless of when/how they are started).

The point is that those kinds of daemons have moved functionality out of the daemon itself and into systemd, so the analogous must be done in the rc scripts.

Well, sd_notify looks pretty simplistic and I guess than writting a helper program to handle this function would not be hard, if ever needed. Now, the simple type of systemd pretends to do optimization: "if the process offers functionality to other processes on the system its communication channels should be installed before the daemon is started up [...] as systemd will immediately proceed starting follow-up units." While it's a good feature to get pallelism, it's not expected by historical sysVinit. So, it should be fine to start the required deamon and let it configure environment or whatever it has to. Once it is fully started or responding, continue the boot process. Yes, this "fully started or responding" is the tricky part but with a fully serialized starting process, it might be doable. Though, I wouldn't expect such converter to create shell scripts roughly equivalent to what systemd does. I think the main pitfall to such a tool would be to try to get equivalent features with shell scripts. Think another way: sysVinit serialize daemons startup. As a consequence, for a minimal working convertion you only need to get the correct order of the series. Advanced features of systemd should highly be ignored from the process. On top of that and for tricky parts of the conversion, it should not be very hard to have conversion tunning from a complementary static source. I mean, trying to convert everything /from unit files only/ in a smart enough way could be very hard. Instead, it would be easier to do the consersion from both unit files AND whatever other source or configuration files (of the convertion tool). IMHO, the best approach of this converter would be to turn it into a micro-framework with _very simple features_ like templating support for init scripts. That way: - simple unit files would not require a template; let the process go automagically; - more complex unit files would only require to write a little template with whatever static-and-dedicated code needed for a given section/function of the built target (the sysVinit script). The systemd-to-sysvinit-converter seems very hackable as a all-in-one python script with only 658 lines. ,-)

Hopefully the Debian guys have found a clever solution for this, I'd be interested to see it :)

I guess you meant "if the Debian guys have found". -- Nicolas Sebrecht

The 28/08/12, Tom Gundersen wrote:

This is the point. If a daemon has been customized for systemd (which some have, and hopefully more will), then it will expect systemd to set up its communication channels for it and pass them to the daemon on startup, it might also expect systemd to do many other tasks which daemons traditionally would do themselves.

Daemons customized to require systemd will actually require systemd. Now, systemd is a Linux only platform tool and most upstream don't target their software to Linux only. I don't expect much daemons requiring systemd to be started. If they do, users who want such tool will use systemd and such daemons would naturally be out of the scope. -- Nicolas Sebrecht

On Tue, Aug 28, 2012 at 10:54 AM, Lukas Jirkovsky wrote:

I'm pretty sure at least Ubuntu will keep patches to make some of such apps work without systemd.

So far we see that whenever systemd is made optional, it is optional at compile-time rather than at run-time (which would have been ideal, and not much more difficult to code). That means our packages cannot support both scenarios at the same time. As to Ubuntu, remember that they lag quite far behind our packages, so while they probably will produce patches, don't expect it to happen in time for it to help us. Notice for instance that Ubuntu supposedly took over consolekit, but no release has happened and without backporting patches from git our consolekit package would be completely broken. In short: avoiding systemd will be a lot of work, and you will be more or less alone in doing it. -t

Hi, Apparently, Gentoo has recently forked udev. [1] I am not completely sure since the main poster is a n00b according to the gentoo forum ratings, but rest of the discussions seems legit. -- Cheers and Regards Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html

Ahh, I thought so. It was only forked yesterday, so there is not much to be expected in terms of changes right now. But going by the number of veterans and others who have commented on it, I thought that it is possible that this is legit. Also, the guys there are talking like they are the one going to be making the changes. -- Cheers and Regards Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html

Am 27.08.2012 10:32, schrieb Joakim Hernberg:

On Mon, 27 Aug 2012 09:48:48 +0200 Tom Gundersen wrote:

...

Since the above quoted statement was made, a decision was taken to move to systemd by default, so it clearly no longer applies. While you are still free to use initscripts, at some point other packages are likely to depend on you booting with systemd (NetworkManager, polkit, Gnome, etc.).

Please support our traditional initscripts as long as possible, as I for one really don't look forwards to systemd, at least not at this point in time. Reasons excluded to avoid yet another flamefest...:(

If you search the archives, you will notice that longer initscripts support is already planned. But this only concerns the booting itself. As consolekit is unmaintained, polkit will soon depend on systemd. The next Gnome version will require systemd - more to come. That said, if you run a machine that does not depend on any of this (like a server), you will probably be able to keep using traditional initscripts for a while. Of course, this may change as the situation changes.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, \begin{quote} But this only concerns the booting itself. As consolekit is unmaintained, polkit will soon depend on systemd. The next Gnome version will require systemd - more to come.... \end{quote} Isn't it possible to start systemd daemon-like if one of those components is used...and stop it again after e.g. stopping Gnome? This won't avoid unnecessary overhead, but at least the boot process etc. could be kept unchanged. Cheers, Jakob -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQO2doAAoJEOl7hkDId7YmpokP/0BCzKUjz/CelgwuAShBC27b Oa5pH73d2BN60mIBDCSvysgH0li8I6MQsDjKTP/QAN/tHFYAyWQGk594rP2jkrVv xCd6JsxQBTTj0Ud+hDdgQ7k63swemnuIBH2h84CLZq1xMXDzoZJVXrKc92/5ZB8m bM158+rT1Lylclh5wq4KXfSsKVjE3nNmAb6nEvyJbVqBZL25MNDEcmVlGqqF986r Aoy+Z2CNJrkbs86WUtH4slS5WZzzM/fPOSytSdAq5Us7eARiqbf9fE8d5QR9KNuW c2W2N1dUU0rDP0p6EAIbxgfEW3o7rZzCRGgking4nIiiLmnQf9XLFTzbqrX17VtF F5FT7MY6e7Lv+IjnMFhU8BtaTdGcN0nyMncyiok/Sp5b7wq9sFKjgCxIafQBLn16 7Y+WCb0rOTboBqoyUMbKAmFBZkzujbuCUsjMX4ga1ruMG3kOfgeUspFIPwloJxMM TOsSS47+g6njvpRtGqRFP2c72RidI/egIVA/1SZPpVJfEgsJU5DuJg1B+iz1yIgk IgPKvEZcB6pJ+gawIEaUheUsuWz8jFGXMPTH4f7gXV61hn7w+J+OAfMwoHTYPQj9 r1raAk1/FRLLN98C4jnu7Jk/iN583WBa3/tgBlqrtlIUPyvzVr/PlJRZrv9Ftb44 p1AnwcueNzojDqsRhtzm =hQlL -----END PGP SIGNATURE-----

Am Mon, 27 Aug 2012 11:30:46 +0200 schrieb Joakim Hernberg :

...

I don't run gnome, but kde is just as bad in this case :( Try Xfce. ;-) http://www.archlinux.org/packages/extra/i686/consolekit/ would suggest

On 27/08/2012 9:39 AM, Heiko Baums wrote: that xfce is not safe in this regard. lxde is as long as you don't use a display manager iirc.

Heiko

On Tue, 28 Aug 2012 07:46:30 +0530 Shridhar Daithankar wrote:

On Monday 27 Aug 2012 11:30:46 AM Joakim Hernberg wrote:

...

On Mon, 27 Aug 2012 10:48:32 +0200

Thomas Bächler wrote:

...

But this only concerns the booting itself. As consolekit is unmaintained, polkit will soon depend on systemd. The next Gnome version will require systemd - more to come.

I don't run gnome, but kde is just as bad in this case :(

care to elaborate?

I have always used KDE. Now I am using it with systemd but AFAIK it does not mandate anything systemd specific.

GNOME OTOH forces you to use pulseaudio :

$ pacman -Qi shows me that kdebase-workspace depends on consolekit, which in turn depends on polkit. The above comment seems to suggest that kde will soon depend on systemd. But who knows, I can imagine that there are so many old time linux users that would hate installing something like systemd even if they use kde as DE. With a bit of luck someone willl step up and maintain an alternative to consolekit/polkit that doesn't require systemd. --- Joakim -- Joakim Hernberg

On 28 August 2012 16:01, Joakim Hernberg wrote:

On Tue, 28 Aug 2012 08:55:06 +0200 Joakim Hernberg wrote:

...

$ pacman -Qi shows me that kdebase-workspace depends on consolekit, which in turn depends on polkit. The above comment seems to suggest that kde will soon depend on systemd.

Maybe I should add that I think this support is only needed by KDE for powermanagement and automounting of media. So conceivably one could live without it if necessary :)

In fact, many Archers have lived without these things for years ever since they became mandatory for the masses. Especially those on WMs. These are the purists, so to say. I don't see systemd or anything like that becoming a problem. The purists will find their way to keep these things out. Having libpulse or systemd "live" on your system isn't going to do any harm while you're adapting to the change. There's always a way to do what you want, and there's always another KISS operating system. Given the resistance that I see, I'm almost sure a separate initscripits project (or a distro fork if necessary) is inevitable. -- GPG/PGP ID: C0711BF1

On Tue, Aug 28, 2012 at 06:36:22PM +0200, Joakim Hernberg wrote:

A distro fork would be the absolute worst outcome imaginable (imo) of the initscripts vs systemd schism...

Assuming you mean a fork of Arch, I agree. But consider ArchHURD downstream. They'll have no choice but to do something different.

On Wed, Aug 29, 2012 at 10:24 AM, Ralf Mardorf wrote:

On Wed, 2012-08-29 at 10:39 +0100, Peter Cannon wrote:

...

Oh and as a side note a rolling release means it rolls, http://www.thefreedictionary.com/roll if it stops because of a breakage or a change in file structure or manipulation that then means it is not rolling it has come to a halt. Just wanted to add that for those I keep seeing on the net saying "It's a rolling release what do you expect?" Judd Vincent meant "You'll never have to upgrade because every pacman- Syu gives you the most recent version." ergo 'It's rolled over to the latest. If a package breaks your system that's fair enough, if changing the file structure or core of your system breaks it that has nothing to do with 'rolling' that's called "I just ripped the wires out of your radio but hey you get to keep all the parts." just wanted to clarify that.

Is Arch a rolling release or isn't it?

It's as rolling as a rolling distro can get. The fact that a rolling release system uses the word "rolling" doesn't qualify the release with every possible meaning of that word In the case of a distribution, it means that we don't get updates for old versions of software, just for the newest version some packager had the motivation to provide. So, it is very distant from the real meaning of "rolling". Unless we'll now receive our updates on a DVD down a hill and it comes rolling to the bottom... :P -- A: Because it obfuscates the reading. Q: Why is top posting so bad? For more information, please read: http://idallen.com/topposting.html ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------

Am 28.08.2012 04:16, schrieb Shridhar Daithankar:

On Monday 27 Aug 2012 11:30:46 AM Joakim Hernberg wrote:

...

On Mon, 27 Aug 2012 10:48:32 +0200

Thomas Bächler wrote:

...

But this only concerns the booting itself. As consolekit is unmaintained, polkit will soon depend on systemd. The next Gnome version will require systemd - more to come.

I don't run gnome, but kde is just as bad in this case :(

care to elaborate?

I have always used KDE. Now I am using it with systemd but AFAIK it does not mandate anything systemd specific.

You can build polkit with either consolekit or systemd support, but not with support for both. consolekit is unmaintained for a while and thus we will switch to building polkit with systemd support instead. Once that happens, you need systemd for certain aspects of KDE to function properly (most prominently, mounting removable file systems).

Thomas Bächler wrote:

...

Please support our traditional initscripts as long as possible, as I for one really don't look forwards to systemd, at least not at this point in time. Reasons excluded to avoid yet another flamefest...:(

If you search the archives, you will notice that longer initscripts support is already planned.

But this only concerns the booting itself. As consolekit is unmaintained, polkit will soon depend on systemd. The next Gnome version will require systemd - more to come.

That said, if you run a machine that does not depend on any of this (like a server), you will probably be able to keep using traditional initscripts for a while.

This is good news ! I maintain a bunch of test-machines (about 10) in a lab and the prospect of moving all of them to a new init system is a bit scary - they are all in a remote place. My environment is openbox/emacs, so initscripts is a perfect fit. Having just moved all the machines to grub2 and resolved the /lib migration, embracing systemd right now appears to be a tiresome job. :-) And I have a server which I stopped upgrading a while ago. :) Sujith