|
|
Subscribe / Log in / New account

The road to systemd for openSUSE 12.1

From:  Frederic Crozat <fcrozat-IBi9RG/b67k-AT-public.gmane.org>
To:  opensuse-factory <opensuse-factory-stAJ6ESoqRxg9hUCZPvPmw-AT-public.gmane.org>
Subject:  The road to systemd for openSUSE 12.1
Date:  Fri, 10 Jun 2011 19:04:14 +0200
Cc:  opensuse-project <opensuse-project-stAJ6ESoqRxg9hUCZPvPmw-AT-public.gmane.org>

Hi all,

systemd is coming for next openSUSE (12.1) scheduled next fall.

I'll help for systemd integration in openSUSE Factory[1] and will act as
an interface between you (openSUSE testers, packagers, developers) and
systemd upstream.

As you might guess, switching boot manager is not a trivial task and
issues will be found. So, we want to have as much feedback and testing
as possible, to try to tackle as much (if not all) issues in time for
12.1.

Here is our action plan, in several phases: 


      * phase 1: detecting current issues with systemd. Install systemd
        package and "manually" boot with it, by adding
        "init=/bin/systemd" at you kernel boot command line. In this
        setup, we want to find ALL the issues caused by switching to
        systemd, so please, check systemd on Factory status page[2] and
        follow the instructions there to fill bug reports. We also want
        to ensure there is no regression, when using legacy sysvinit
        initscripts with systemd as boot manager.
      * phase 2: systemd-sysvinit package installed by default and
        replace sysvinit. 
      * phase 3: providing systemd unit files to replace legacy sysvinit
        initscripts: this is a huge task which won't be completed before
        openSUSE 12.1, but it can be parallelized among a lot of people
        (ideally, each packager should be able to create unit systemd
        file). And we should also split this effort in manageable
        milestones :
              * phase 3.1: GNOME and KDE live CDs should only use
                "native" systemd, without any sysvinit involved
              * phase 3.2: installed system using GNOME and KDE live CDs
                be a "native" systemd (this involves testing additional
                paths in live installer)
              * phase 3.3: install from DVD for GNOME and KDE should be
                "native" systemd
Of course, providing systemd unit file should not be a pure "openSUSE"
task, because the ultimate goal for those files is to be
cross-distribution and merged in relevant upstream projects. And we also
don't want to duplicate effort which is starting in other distributions
like Fedora, so, collaboration is key. I strongly recommend reading
systemd for Administrators, Part III[3] post about the conversion (and
also all other posts : systemd for Administrators #1, #2, #3, #4, #5,
#6, #7,#8 they are highly instructive[4]). 

For discussing / helping with systemd integration for Factory, please
use opensuse-factory mailing list or go to #opensuse-factory IRC channel
on Freenode.

We need your help to make sure openSUSE 12.1 will use systemd at 200% ;)

[1]http://en.opensuse.org/SDB:Systemd
[2]http://en.opensuse.org/openSUSE:Systemd_status
[3]http://0pointer.de/blog/projects/systemd-for-admins-3.html
[4]http://0pointer.de/blog/projects/systemd-for-admins-1.html
http://0pointer.de/blog/projects/systemd-for-admins-2.html
http://0pointer.de/blog/projects/systemd-for-admins-3.html
http://0pointer.de/blog/projects/systemd-for-admins-4.html
http://0pointer.de/blog/projects/three-levels-of-off
http://0pointer.de/blog/projects/changing-roots.html
http://0pointer.de/blog/projects/blame-game.html
http://0pointer.de/blog/projects/the-new-configuration-files
-- 
Frederic Crozat <fcrozat-IBi9RG/b67k@public.gmane.org>
SUSE

-- 
To unsubscribe, e-mail: opensuse-project+unsubscribe-stAJ6ESoqRxg9hUCZPvPmw@public.gmane.org
For additional commands, e-mail: opensuse-project+help-stAJ6ESoqRxg9hUCZPvPmw@public.gmane.org





to post comments


Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds