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

Fri Jul 15 01:08:38 CEST 2011

Colin Guthrie <mageia at colin.guthr.ie> writes:
+
+>> Secondly, what should be the correct way of supporting systemd in a
+>> package? In Mandriva, I thought on adding a --with flag to
+>> enable/disable systemd, but in most cases it does (almost) nothing. All
+>> services which want to support systemd only need to place their files
+>> into /lib/systemd - and that's it. Should we support opting-out of
+>> systemd in specs? I believe fcrozat is having the same dilemma in SuSE
+>> now as well, and he settled on some common packaging macros.
+>
+> IMO, unless something goes horribly wrong with systemd (which I very
+> seriously doubt will happen - it's actually been amazing to watch this
+> project from birth to wide adoption) I'd say we just jump right in and
+> package the units unconditionally. They don't really take up much space
+> and do nothing if you choose to not use it for the time being. I think
+> by mga3 we'll likely *only* offer systemd (if not in mga2), so I'd say
+> putting in effort to opt out now is pretty much not going to be worth it.
+
+I agree, it does not seem useful to avoid shipping systemd services.
+
+Though, when systemd is enabled, what happens if one has both systemd +
+sysvinit services files installed for a given package?
+Will the initscript be run in addition to the systemd service?
+
+>> 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?
+>
+> I vote to put them in the same place as the initscripts-based ones. As I
+> predicted above, I reckon it won't take too long for systemd to be the
+> only system offered and obsoleting all those subpackages would be a bit
+> of a PITA down the line. And if systemd isn't used those files do
+> nothing, so no harm done.
+
+Agreed as well.
+
+>> 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.
+>> 
+>> So, that's it for now from my part..
+>
+> I'd like option 2 please! :) It doesn't exclude using option 1 along
+> with it (I was doing this for a while), so it's most flexible.
+
+Option 2 seems good as well, but does it really have to uninstall
+sysvinit? Isn't it enough to put some alternatives symlinks for
+/sbin/init?
+
+-- 
+Olivier Blin - blino
+