[Mageia-dev] [Mageia 2 specifications] Systemd or not systemd

Sat Jul 16 02:53:47 CEST 2011

Le mercredi 13 juillet 2011 à 22:47 -0300, Eugeni Dodonov a écrit :
+
+> Almost finally, should the systemd files belong to the main package, the
+> same way as they do with initscripts-based one (e.g., the package would
+> provide /lib/systemd/system/%{name}.service together with
+> %_sysconfig/rc.d/init.d/%{name} for example), with no extra subpackages or
+> flags - or should all systemd-specific files go into %{name}-systemd package
+> for example? What do you think?
+
+Everything in 1 package.
+
+> And finally, what does seems to be the best way of starting to use systemd
+> in cauldron? I have thought on 3 alternatives:
+>  - easy way, only having it packaged, but not
+> providing/obsoleting/conflicting with sysvinit. This way, it will work when
+> kernel is booted with init=/bin/systemd (the least invasive way)
+>  - compatible way (like in Mandriva) - it is available, systemd-sysvinit
+> conflicts with sysvinit, so if someone installs systemd-sysvinit, sysvinit
+> goes away and systemd is run by default. This seems to be the most sane way
+> to me (but I could be biased), and it is easiest one for testing
+>  - ultimate way - systemd provides and obsoletes sysvinit and its goodies.
+> This way, systemd will be the only one (e.g., highlander style). This is how
+> fedora did it if I am not mistaken, but I am not sure if it the best way.
+
+Option 2 for Mageia 2, and option 3 for Mageia 3.
+
+People on Fedora list were quite reluctant to changes ( to say the least
+), and I am pretty sure that someone will hit a unrelated corner case in
+the last minute. Rtp was not really fond of systemd on arm and embedded
+system either.
+
+So we should keep the possibility of letting people choose for Mageia 2.
+
+Also, systemd was reverted for f14, and while it was working fine for
+me, I would rather make sure we have a reputation of being cautious and
+choosing the quality rather than trying to steal the reputation of
+Fedora. 
+
+-- 
+Michael Scherer
+
+