Public SourceMage Discussion List

[flux <flux AT sourcemage.org>]

Vlad Glagolev (stealth AT sourcemage.org) wrote [12.08.18 05:20]:
> Since we still provide a choice in anything that is possible, we must
> answer a couple of questions before taking the decision:
> 
> 1. Does it depend on specific kernel branch (not below than ..., etc.)?
> 2. Does it require specific CONFIG_'s in kernel config?
> 3. Does it depend on any other spells or their forks (which are still
> not in master branch for compatibility/awfully-tested-in-production
> state reasons)?
> 
> Even if systemd will be the only way to launch a notebook in the near
> future, our switching process must be preceded by a good plan.
> I'm not against systemd, I'm against the way you're trying to bring it
> into the distro, and, therefore, to the community.
> 
> First of all, one spell with a hundreds of service files related to all
> different software looks silly to me. It's much better and more
> universal and centralized way -- to add systemd support to sorcery and
> include service files in "systemd.d" folders of spells, like we already
> have for init, xinetd, pam.
> 
> So we need to write a simple patch for sorcery that would bring systemd
> support in and include it for, let's say, 1.16 release.
> 
> Second, systemd work is unacceptable for regular rolling out stable
> grimoire releases (where all updates go in, bringing new features to
> system software, fixing security flaws, etc.).
> All work related to it must be done in a branch, or, if possible
> -- in another grimoire, like it was made with modular Xorg. Remember
> how many years did it take to switch to it? And that's only graphical
> part of a system. Init system is more serious, and infiltrates much
> deeper into OS and touches many stuff in it, from low-level acpi to
> high-level things like apache or mysql.
> 
> Next we will have to organize switching process and test it as hard as
> possible -- then -- merge all our work into master branch, while
> providing a choice/warning to the end user.
> 
> Manual user intervention must not be needed during this process, at
> least up to level 3 in sysv terminology.
> 
> I've seen many people left Arch recently cause of the last "breaking"
> steps and management mistakes, and it makes me sad when you're still
> comparing us with it, because we're too different for that.
> SMGL is still a distribution that gives all the power of customization
> to SA along with powerful package management system that keeps it as a
> rock-solid OS if you know what you're doing. Let's try not to ruin this
> philosophy with unweighed actions.

While I agree with your principles about bringing in new (especially
critical) spells by setting up clear transition plans and ensuring
stability, I have to ask: who and what are you talking about?

Ladislav only presented an FYI. David, in addition to making his own
preference clear, raised several possibilities for how we could move
forward if non-systemd udev becomes an impossibility. However, no one is
actually bringing anything in (yet), at least not beyond what was
already done in branches quite some time ago.

Granted, the link to the Arch discussion about migrating to systemd is
superfluous and irrelevant to our distro, I still don't see who/what
you're directing your argument against (though, again, I do agree with
the principles).

I'm not sure the argument about "hundreds of service files" is valid
though. Whether the service files/init scripts are scattered across a
multitude of subdirectories (.../*/{init.d,systemd.d,...}) or all
located in one place together, the files need to be there regardless.
Everyone has different ideas/preferences about
organization/categorization (just look at our keywords issue), so
ultimately it won't matter -- there will always be people unhappy with
the organization scheme, no matter what the scheme is. If you can
demonstrate a real technical reason for one or the other then this
argument would have more weight.

-- 
Justin "flux_control" Boffemmyer
Cauldron wizard and general mage
Source Mage GNU/Linux
http://www.sourcemage.org

Attachment: pgpoJ_1Sd7JMc.pgp
Description: PGP signature