Re: Jessie and Systemd integration
Am Mittwoch, 17. September 2014, 17:16:57 schrieb T.J. Duchene:
> I'm asking this on the user list not because I am trying to incite yet
> another debate over the merits of Systemd, but because I am assuming that
> the user list probably has the best chance of reaching out to the most
> people to get an answer.
>
> I do not care which init is better for what. I do not care about the
> Systemd versus SysV arguments. The decision has been made by the
> Debian TC. So be it.
>
> My concern is the future of Debian for situations where the use of Systemd
> is not acceptable. I'm curious to find out how Systemd as the default is
> going to work on Jessie/Debian 8. When the words, "as default" is offered,
> that assumes that there are supported alternatives available.
>
> What I want to know with complete surety is:
>
> a) If I will have to have systemd installed even if I do not want it.
I wanted to say no as I thought systemd-shim *and* cgmanager together can
replace it, but according to
merkaba:~> LANG=C apt-get purge systemd
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
amor analitza-common blinken cantor cantor-backend-kalgebra
filelight kaccessible kalgebra kalgebra-common kalzium kalzium-data
kanagram kbruch kcharselect kcolorchooser kde-config-cron
kde-icons-mono kdeaccessibility kdeadmin kdeartwork kdeartwork-style
kdeartwork-theme-window kdeartwork-wallpapers kdeedu
kdeedu-kvtml-data kdegraphics kdegraphics-mobipocket
kdegraphics-strigi-analyzer kdegraphics-thumbnailers kdemultimedia
kdenetwork kdenetwork-filesharing kdetoys kdeutils kdf kgamma
kgeography kgeography-data kgpg khangman kig kiten klettres
klettres-data kmag kmousetool kmplot kolourpaint4 kppp krdc
kremotecontrol krfb kruler ksaneplugin kscd kstars kstars-data
ksystemlog kteatime ktimer ktouch ktouch-data kturtle ktux kuser
kwordquiz libanalitza5abi1 libanalitzagui5abi1 libanalitzaplot5abi1
libkdeedu-data libkeduvocdocument4 libkiten4abi1 libntfs10
libpulsedsp libqmi-proxy libwebrtc-audio-processing-0 marble pairs
parley parley-data plasma-scriptengine-superkaramba print-manager
pulseaudio-utils qtdeclarative4-kqtquickcharts-1 rocs step
Use 'apt-get autoremove' to remove them.
The following packages will be REMOVED:
colord* gvfs* gvfs-backends* gvfs-daemons* hplip* hplip-gui*
kde-full* kde-plasma-desktop* kde-plasma-netbook* kde-standard*
libpam-systemd* network-manager* packagekit* packagekit-tools*
plasma-nm* plasma-widget-networkmanagement* policykit-1*
policykit-1-gnome* polkit-kde-1* printer-driver-postscript-hp*
systemd* udisks2*
0 upgraded, 0 newly installed, 22 to remove and 218 not upgraded.
After this operation, 36.5 MB disk space will be freed.
Do you want to continue? [Y/n] ^C
merkaba:~#130>
it needs to be installed for *some of the KDE and GNOME stuff, this doesn´t
work. This might be a problem with dependencies. I think the culprit here
is libpam-systemd, yes, it is:
Depends: libc6 (>= 2.17), libcap2 (>= 1:2.10), libpam0g (>= 0.99.7.1),
systemd (= 215-4), libpam-runtime (>= 1.0.1-6), dbus,
systemd-sysv | systemd-shim (>= 7-2)
So its the logind thing again I think. Maybe libpam-systemd could be made
to work when installed stand alone, but I doubt it.
While its only a few package removed… I bet it would make quite some
trouble:
No network manager, no udisks, no policy kit, I bet that would cripple
current KDE and GNOME desktops a lot.
> b) If completely purging Systemd and using an offered alternative break or
> otherwise hamper the packaging system.
>
> If it is a case where systemd is required to be used, I might have to move
> some of my work off of Debian to Gentoo or FreeBSD.
I understood it that you will be free to go without systemd, but maybe the
tech CTTE only stated that you can *use* another init. And well… my
understanding was wishful thinking it seems.
We have two ctte decisions:
Therefore, the resolution reads:
We exercise our power to decide in cases of overlapping jurisdiction
(6.1.2) by asserting that the default init system for Linux
architectures in jessie should be systemd.
Should the project pass a General Resolution before the release of
"jessie" asserting a "position statement about issues of the day" on
init systems, that position replaces the outcome of this vote and is
adopted by the Technical Committee as its own decision.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6734
The issue of init system support recently came to the Technical
Committee's attention again.[1]
For the record, the TC expects maintainers to continue to support
the multiple available init systems in Debian. That includes
merging reasonable contributions, and not reverting existing
support without a compelling reason.
[1] See #746715 for background.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746715#278
Well, none of these say anything about whether systemd needs to be
installed. It says only that systemd is the default, and one can Debian
*supports* the other as well.
Maybe that can use a further clarification, but forcing onto people to
implement a replacement of libpam-systemd might also not be wise.
So it boils back to having an alternative replacement option. Maybe what
the OpenBSD people do can be used later on.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: