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

Thu Jul 14 23:26:37 CEST 2011

'Twas brillig, and Eugeni Dodonov at 14/07/11 02:47 did gyre and gimble:
+> On Tue, Jul 12, 2011 at 09:48, Colin Guthrie <mageia at colin.guthr.ie
+> <mailto:mageia at colin.guthr.ie>> wrote:
+> 
+>     'Twas brillig, and Eugeni Dodonov at 12/07/11 13:15 did gyre and gimble:
+>     > If nobody objects, I could help with that. Mandriva certainly gave a
+>     > large experience on how to integrate systemd into the system without
+>     > killing traditional sysvinit alternative.
+>     >
+>     > It would also be extremely interested to have native systemd services
+>     > which use most of systemd features (like sound and alsa scripts, which
+>     > we discussed with Colin and Andrey Borzenkov some months ago but never
+>     > got to implement properly).
+> 
+>     Massive +1 for systemd and massive +1 Eugeni wanting to help out! \o/
+> 
+>     I'll try and help out in bits and bobs too, tho' time is always a
+>     problem!
+> 
+> 
+> 
+> Ok, some n00b questions arise from my part, sorry if they seem too basic
+> - I am only catching up with mga style of development :).
+> 
+> Systemd 30 is out, with lots of nice changes, so I think we should use
+> it now as we are quite early in the release cycle. It is working on my
+> machine, but before doing something about it, I prefer to hear opinions :).
+
+Well, IMO (for what it matters) I'm massive for using it ASAP!
+
+> Firstly, systemdrequires udev >= 172, what is the policy to update it?
+> According to 'mgarepo maintdb get udev', it has no maintainers, does
+> anyone objects if I grab/update it as well?
+
+I think that would be most welcome!
+
+> 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.
+
+If anyone else feels super strongly to the contrary, speak up now or
+forever hold your peace :D
+
+> 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.
+
+> 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.
+
+If all goes well for those testing it, we can vote on whether we jump in
+with both feet :)
+
+That's my take on it anyway!
+
+:)
+
+Col
+
+
+
+-- 
+
+Colin Guthrie
+mageia(at)colin.guthr.ie
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited [http://www.tribalogic.net/]
+Open Source:
+  Mageia Contributor [http://www.mageia.org/]
+  PulseAudio Hacker [http://www.pulseaudio.org/]
+  Trac Hacker [http://trac.edgewall.org/]
+