On Thu, Sep 27, 2012 at 06:51:17PM +0200, Bernhard M. Wiedemann wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 27.09.2012 17:03, schrieb Michal Vyskocil:
On Tue, Sep 25, 2012 at 03:57:22PM +0200, Bernhard M. Wiedemann wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 07.09.2012 15:43, schrieb Michal Vyskocil:
Hallo all,
Reading the discussion about dropping sysv init, it seems the number of people are opposing against it is big. I have an idea for people wiling to maintain and use it in the future.
It is trivial to create a community project dedicated to that task. All you need is to have a devel project (Base:sysvinit), where you will maintain sysvinit and all needed init scripts. As our software stack is really powerfull, it can be done easily. This is the snippet of the spec file providing the init script for vsftpd.
Name: vsftpd-sysv Description: Sysvinit script for vsftpd Supplements: packagageand(sysvinit:vsftpd) Requires: sysvinit Requires: vsftpd Source0: vsftpd.init
%post %{inserv ...
The biggest advantage is that there will be a group of people taking a care about sysvinit, which is better from what we have now.
The disadvantage (or maybe an advantage) is that the amount of needed work will be probably huge, especially adapting on upcomming changes in Factory. I'm talking especially about Gnome, where systemd is (planned to be) integrated into core parts (gdm, gnome-session, ...) and the Supplements trick won't work here, so the $sysvinit project will be enforced to provide own packages in some cases.
But in anycase, the future is in your hands ...
BTW: I am not going to be a part of such project as I support systemd migration - I just wanted to raise my idea to you
Regards Michal Vyskocil
Please count me in to help with sysvinit maintenance.
Hallo Bernhard,
it's cool to have someone is willing to do the work - anyway I do not want to work on sysvinit, I'm the one from the enemy camp ;-) So please take the chance and you can (at least try to) define things you like.
OK. To better coordinate this work, I started http://en.opensuse.org/openSUSE:Sysvinit
Feel free to add yourself as contributor there, add details on problems and/or solutions.
I would prefer the /etc/init.d/xxx scripts to remain in the related packages, as is also the case for systemd .service files.
As a maintainer of few things uses sysv/sysd things, I must say I will be much happier to not taking a care about sysv limitations.
Which limitations cause most trouble to you?
In my specific case, User=, Group= is awesome for Java software maintainer. For instance tomcat under sysvinit is started in so hacky way, because we have to do su. But you have to export variables to the process as well, so you have to parse the file, ... - many enterprise apps rely on such start ... which is hard to debug and understood. With systemd (even if it was never designed for Java software) I have been working with Fedora maintainer to cut it off, so only one script is needed to handle return code and change the wd. There's only one thing prevents me to go through pure-systemd approach and it's variable support in WorkingDirectory=.
There are still too many situations where sysvinit is needed. Be it those arm systems with old kernels on which systemd does not run (and porting those patches is hard),
JFI: but is there any use case to run factory or 12.3 on arm system with the old kernel not supported by systemd? Or have I missed the point?
openSUSE Factory is the only openSUSE we build for arm(v5el) atm. There will be 12.2 for armv7 soon at least.
LXC is another use-case where you can have a newer VM user-space on an older host kernel.
Sure, that'd be the problem - LXC guests expecting systemd will need newest kernel. On the other hand, upgrading host's kernel might be less work, than supporting nonsyv targets in near future. Even enterprise distros increase kernel version from time to time ;-)
Also, there are cases where it is hard to boot with an initrd because of boot/system constraints (coreboot, U-Boot, User-Mode-Linux, ...). People then just build the relevant drivers into their kernel. That is yet another thing we should not break.
Systemd does not require initrd at all - it requires some recent version of kernel + relevant userspace utils (util linux?) only. Regards Michal Vyskocil