Re: Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)
Hi Ian, On Di 03 Dez 2019 13:54:40 CET, Ian Jackson wrote: * Should I adopt Guillem's framing as a preamble to my own proposal ? (Should this be a new alternative or a replacement?) * Would Guillem's framing make a good preamble to Dmitry's option ? * Or do the supporters of Guillem's option favour some other combination of possible answers to the specific questions ? Personally, I think that the full scope of the tendency spectrum regarding init systems is +/- covered by the available proposals. However, not all proposals provide proper guidance how to act and react in certain corner and/or non-corner cases. I think, this lack of specifics can be amended with a follow-GR that goes into details and fine-tunes the voted for proposal. Personally, I am much more on the multiple init systems side than on the systemd side, however, if the majority in Debian wants to see systemd-only, you can safe the drafting time today for other valuable tasks. My 2¢, light+love Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpyIX_aSZYC3.pgp Description: Digitale PGP-Signatur
Re: Proposal: Reaffirm our commitment to support portability and multiple implementations
Hi, Am Samstag, 30. November 2019 schrieb Guillem Jover: > Hi! > > I think the current GR is incorrectly framing the problem at hand, > as if it was just an init system selection. It seems to me, that an > init system is in principle just one of the many technologies we ship > and integrate. But at least when it comes to systemd, choosing that in > detriment to anything else, has a cascading effect of deciding on and > closing doors on a wide range of technologies which have been declared > incompatible by systemd upstream or by those other technologies. > > For example the claims on "cross-distribution standards and > cooperation", are pretty much restricted to GNU/Linux (glibc-based), > not even say musl-based systems, or many other variations. systemd > provides many nice features, but at the same time, as with any > software, not all of them fit or are sufficient for all use cases or > requirements, and people do want or have to use alternatives for many > valid reasons. > > > I'm thus proposing the following: > > X< > Title: Reaffirm our commitment to support portability and multiple > implementations > > The Debian project reaffirms its commitment to be the glue that binds > and integrates different software that provides similar or equivalent > functionality, with their various users, be them humans or other software, > which is one of the core defining traits of a distribution. > > We consider portability to different hardware platforms and software > stacks an important aspect of the work we do as a distribution, which > makes software architecturally better, more robust and more future-proof. > > We acknowledge that different upstream projects have different views on > software development, use cases, portability and technology in general. > And that users of these projects weight tradeoffs differently, and have > at the same time different and valid requirements and/or needs fulfilled > by these diverse views. > > Following our historic tradition, we will welcome the integration of > these diverse technologies which might sometimes have conflicting > world-views, to allow them to coexist in harmony within our distribution, > by reconciling these conflicts via technical means, as long as there > are people willing to put in the effort. > > This enables us to keep serving a wide range of usages of our distribution > (some of which might be even unforeseen by us). From servers, to desktops > or deeply embedded; from general purpose to very specifically tailored > usages. Be those projects hardware related or software based, libraries, > daemons, entire desktop environments, or other parts of the software > stack. > X< > > Thanks, > Guillem > Seconded. Mike -- Gesendet von meinem Fairphone2 (powered by Sailfish OS).
Re: [draft] Draft text on Init Systems GR
Hi Matthias, On Sa 09 Nov 2019 23:57:08 CET, Matthias Klumpp wrote: Am Sa., 9. Nov. 2019 um 23:01 Uhr schrieb Mike Gabriel : [...] Isn't as side-question that is on the table with this GR: what about the future of non-Linux variants of Debian. If systemd becomes _the_ init system of focus in Debian (by vote, not only de facto), kFreeBSD and Hurd will certainly have more of their difficulties, more than they have now. [...] [...] The one thing I am against though is the non-Linux ports holding back innovation and experimentation on the Linux ports. If we go with the lowest common denominator, we can't realistically move forward, ever. I agree with that and at the same time think that we (Debian) should do our best at being universal (that's what the upcoming vote is about). Greets, Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpxvTxwbfvu8.pgp Description: Digitale PGP-Signatur
Re: [draft] Draft text on Init Systems GR
Hi, On Do 07 Nov 2019 19:59:49 CET, Sam Hartman wrote: No, the difference intended between choice 2 and 3 is about how we handle technologies like elogind, or a mythical technology that parsed sysusers files, rather than how we handle starting daemons. I'd suggest leaving elogind entirely out of the discussion, here. The elogind fork of the systemd component systemd-logind only kicks in, just like systemd-logind, once a user logs into the session. As I get it, the rest of the GR draft is about system services initialization, not user session services startups. If systemd was mandatory, user session services would be handled by systemd-logind. If systemd was replaceable by some other init system, than there would be (at least) two options: - still use systemd-logind for user session service startups (and have all the systemd entanglement package-wise) [1, 2] - use elogind (drop-in replacement for systemd-logind, no entanglement with systemd as a system service orchestrator) Isn't as side-question that is on the table with this GR: what about the future of non-Linux variants of Debian. If systemd becomes _the_ init system of focus in Debian (by vote, not only de facto), kFreeBSD and Hurd will certainly have more of their difficulties, more than they have now. light+love, Mike [1] in Debian jessie this was possible [2] Ubuntu used to have a phase when upstart was handling system services and systemd-logind was handling user session services -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpFxlp1eGHIc.pgp Description: Digitale PGP-Signatur
Re: [draft] Draft text on Init Systems GR
qi frameworkintegration gdm3 gnome-color-manager gnome-control-center gnome-disk-utility gnome-music gnome-session gnome-settings-daemon gnome-shell gnome-sushi gnome-system-tools gvfs gvfs-backends gvfs-daemons gvfs-fuse k3b kactivitymanagerd kaffeine kate kde-cli-tools kde-config-gtk-style kde-config-screenlocker kde-config-sddm kde-runtime kde-style-breeze kde-style-breeze-qt4 kde-style-oxygen-qt5 kde-style-qtcurve-qt5 kdeconnect kdelibs5-plugins kgamma5 khelpcenter khotkeys kinfocenter kinit kio kio-extras kmenuedit konsole konsole-kpart kpackagelauncherqml kscreen ksshaskpass ksysguard ktexteditor-katepart kwalletmanager kwin-common kwin-style-breeze kwin-x11 libcolorcorrect5 libk3b7 libk3b7-extracodecs libkf5auth5 libkf5bookmarks5 libkf5cddb5 libkf5configwidgets5 libkf5declarative5 libkf5iconthemes-bin libkf5iconthemes5 libkf5kcmutils5 libkf5kdelibs4support5 libkf5kdelibs4support5-bin libkf5khtml-bin libkf5khtml5 libkf5kiocore5 libkf5kiofilewidgets5 libkf5kiogui5 libkf5kiowidgets5 libkf5newstuff5 libkf5newstuffcore5 libkf5notifyconfig5 libkf5parts-plugins libkf5parts5 libkf5plasma5 libkf5plasmaquick5 libkf5quickaddons5 libkf5runner5 libkf5style5 libkf5sysguard-bin libkf5texteditor-bin libkf5texteditor5 libkf5textwidgets5 libkf5wallet-bin libkf5xmlgui5 libkf5xmlrpcclient5 libkscreenlocker5 libksignalplotter7 libkwin4-effect-builtins1 libokular5core8 liboxygenstyle5-5 libpam-systemd libpolkit-gtk-mate-1-0 libpolkit-qt-1-1 libpolkit-qt5-1-1 libpowerdevilcore2 libprocessui7 libtaskmanager6 libvirt-daemon-system libweather-ion7 lightdm lxde lxde-core lxpolkit lxqt lxqt-core lxqt-panel lxqt-policykit lxqt-powermanagement lxsession lxsession-logout mate-applet-brisk-menu mate-applets mate-control-center mate-desktop-environment mate-desktop-environment-core mate-indicator-applet mate-indicator-applet-dbgsym mate-panel mate-polkit mate-polkit-bin mate-power-manager mate-settings-daemon mate-settings-daemon-dev mate-system-tools mate-tweak mate-user-share milou modem-manager-gui nautilus nemo nemo-fileroller network-manager network-manager-gnome network-manager-openvpn network-manager-openvpn-gnome network-manager-pptp network-manager-pptp-gnome network-manager-strongswan network-manager-vpnc network-manager-vpnc-gnome okular openbox-lxde-session packagekit packagekit-tools plasma-desktop plasma-discover plasma-framework plasma-integration plasma-pa plasma-workspace policykit-1 policykit-1-gnome polkit-kde-agent-1 powerdevil python-jarabe qml-module-org-kde-draganddrop qml-module-org-kde-kcm qml-module-org-kde-kconfig qml-module-org-kde-kcoreaddons qml-module-org-kde-kio qml-module-org-kde-kirigami qml-module-org-kde-kquickcontrols qml-module-org-kde-kquickcontrolsaddons qml-module-org-kde-kwindowsystem qml-module-org-kde-qqc2desktopstyle qml-module-org-kde-runnermodel sugar-pippy-activity sugar-session systemd-sysv systemsettings udisks2 user-manager veyon-master The following NEW packages will be installed: sysvinit-core 0 upgraded, 1 newly installed, 191 to remove and 40 not upgraded. Need to get 147 kB of archives. After this operation, 356 MB disk space will be freed. Do you want to continue? [Y/n] ``` At times of Debian jessie, sysvinit-core was a drop-in replacement for systemd-sysv, IIRC no removal of other packages would occur back then. I second the statement, that it's not that simple anymore, these days, to switch back to sysvinit-core. I heavily depends on the package potpourie you have on the machine. Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpJUfutnnabp.pgp Description: Digitale PGP-Signatur
