Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] udev & systemd

sm-discuss AT

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Vlad Glagolev <stealth AT>
  • To: sm-discuss AT
  • Subject: Re: [SM-Discuss] udev & systemd
  • Date: Sat, 18 Aug 2012 00:19:26 +0400

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.

Dont wait to die to find paradise...
Vlad "Stealth" Glagolev

Attachment: pgpxJOYfj5Tci.pgp
Description: PGP signature

Archive powered by MHonArc 2.6.24.

Top of Page