What If .........Slack needs Systemd (Slackbuilds)
 

Please read below first before posting:

This post is meant for helping everyone that is interested in running systemd on Slackware.

THIS IS NOT A PLACE FOR FLAME WARS.

If in the future Slackware needs to switch to systemd, we have slackbuilds, unit files, etc ready for them to use.

As Everyone knows: GNOME and KDE will be switching to use Systemd.
This will be as it looks now 90% sure a hard dependency.

Because of this (for me GNOME), the dropline gnome devs started with developing of systemd on slackware.
Dropline Gnome has its own build system, so I have made Slackbuilds from the systemd parts, and I intend to extend these with packages that needs to use unit files, or as explained below rebuild.

- Udev will be soon completly integretad into systemd.
so a dozen packages that are requiring libudev.so.0 will need to be rebuild to link against the new libudev.so.1 (currently libudev.so.0 is linked to libudev.so.1 in the Slackbuild)

- ConsoleKit is currently not actively maintained. The focus has shifted to the built-in seat/user/session management of systemd called http://www.freedesktop.org/software/...d.service.html

- User sessions are registered in logind via the pam_systemd(8) PAM module. (this is why the DE's are switching to systemd).

SlackBuilds can be found at: SlackBuilds Systemd

A small howto can be found here: Systemd for Slackware

If you wish to help in making slackbuilds, improving slackbuilds, or creating documentation for it. you can reply that here, or send me an email at < bartgymnast - at - hotmail - dot - com >
You can also find me on irc.freenode.org in channel #dropline

this enables at least some real world comparisons, see what works how and so on.
would like to have more time to give it a trial right now, but this has to wait some time.
thanks for the effort

I thought the Gnome devs said they weren't going to make any hard dependencies for systemd.

they said during the time, it was requested and they would review it with each release.
For now it is still not a hard dependency.
However without systemd, you need to patch a lot of packages to get all functionality.

And some goes for Kwin (KDE), read Alienbob's blog post http://alien.slackbook.org/blog/kde-...kware-current/
I replied in a post later that my interpretation on this was wrong. and that KDE is thinking about maybe using systemd, but nothing has been decided.

My planning for the next packages are:

util-linux
bluez
udisks
upower
udisks2
system-config-printer
lvm2
libatasmart
wayland
mesa
glib2
fontconfig
gobject-introspection
polkit - is now available
pango
gdk-pixbuf2
gtk+3
NetworkManager
openssh - is now available

No, you use descriptive thread titles, please! Not "What If ........"

done

Please do not give your own interpretation to these issues and make it appear those are the actual opinions of others.
Where do you get the "Everyone knows: ... KDE will be switching to use Systemd" and "it looks now 90% sure a hard dependency" from?
If you read my post, and click through to the article by Martin Graesslin, you will notice that he only talks about "may be" and "we do not yet depend on systemd and have no concrete plans to depend on it. It’s just that it looks like the Wayland system compositor will use systemd".
And Wayland will be only one of the supported compositors, next to the X.Org compositor.

Eric

I sincerely hope kwin doesn't force Systemd upon users. At the very least, kwin is not needed to run kde. Either way, despite not being a great fan of Systemd, i acknowledge your efforts in creating Slackbuids bartgymnast. I won't test them, but thank you for sharing.

EDIT:

I haven't been participating in the Gnu/Linux community for a few months. I was looking forward to Wayland, i really hope it doesn't force Systemd on us.

I know when I compiled gala (WM) a few days ago, I had to do some creative versioning to get away from having systemd as a dependency. It was possible, but I had to use some earlier versions on some libraries.

Also, I was still unhappy with some of the things I had to install.

Alien,
For Gnome it looks 90% to become a hard dependency, I should have stated that better.

and indeed, kwin is a maybe, but not yet (sorry for stating this wrong)
and yes it looks indeed that the wayland compositer will use systemd.

Apart from that, comments on the SlackBuilds and etc. are welcome

Wayland itself has in no way a dependency on systemd. It is up to the developers of WMs/DEs if they want their compositors (or other parts of the DE) to be dependent on systemd.

@bartgymnast: Thanks for those SlackBuilds, I will definitely have a look at that once I have a little bit more time.

Indeed, Wayland has absolutely no dependencies on systemd. However, some DE's are considering requiring systemd for Wayland use because Wayland is lacking certain features that X had, such as login facilities (systemd has logind, thus the theoretical dependency). People seem to think KWin will require systemd because KWin's maintainer is a fan of systemd. To be perfectly fair, since Wayland doesn't have good (any) login facilites, systemd's logind is a tempting option. But he has never stated (that I can find) that KWin will require systemd at any point in the future.

Concerns over GNOME are, perhaps, a little more justified, because they intend to move to systemd in the future. They don't just mean logind, either - they already use systemd for power management.

I would not be worried about KDE suddenly dumping every non-systemd distro. Right now, they are kinda maybe considering using systemd with Wayland in the future perhaps. They have said nothing about X, and I don't think X is moving for a while yet. Wayland may be ready and stable, but it hasn't 'arrived'.

In the end, I don't care that much about what init I use. If Pat decides in the future that systemd's the way to go, then I'll follow. If not, then not.

If I'm not mistaken the hardlinked systemd dependency in Gnome can actually be deactivated. I think DropLine does this.

Reaper, what do you mean?

Dropline is having testing with systemd yes. is it required as hard dep of gnome, NO (atleast not yet)
This post/topic is not about that. Its for having slackbuilds with systemd.
So if people are interested to try it out, they can (without installing Dropline Gnome)

if and let me repeat, if slack needs to/or is going to switch to use systemd.
there are slackbuilds ready that the dev team could use (could, they dont need to).

Also people that have been testing this will be more familiar with how things work.

One does not simply "need" systemd.

Couldn't resist.

You sir, are a true subgenius!

Do I need to remove ConsoleKit and udev or any other packages?
I will test you systemd packages.

You'd be best to wait for an official package if one ever comes. Someone already attempted this and the were left with a mess. You'd basically have to rebuilt about 75% of the core system in the /a directory and then bring in other software that isn't in /a as well like dbus and glib as well as other non-essential packages.

Go read the LinuxFromScratch 7.3 systemd book for what all would have to be done. And you'll notice that LFS 7.4 and the SVN books don't have it either.

ReaperX7, can you go somewhere else.
Go read first post.

This post is to test, improve slackbuilds for optimizing systemd on slackware.
its not for telling people what they cant do, its their own discision.

and tuxbg, you dont have to delete ConsoleKit, however you will need to replace udev

upgradepkg udev%systemd

Sorry but selling snake oil doesn't sit well with me. You can do what you please, but if you are so hell bent on making a systemd Slackware, then go make a fork. Slackbuilds are one thing but to actually use systemd it requires rebuilding the core of Slackware. You don't just make a Slackbuild of systemd. You have to rebuild Slackware at the core.

Up till now all you preached is all what Poettering has said, but you repeatedly have failed to even acknowledge that all that you've preached systemd will innovate, improvise, and improve already has been implemented without systemd but using existing toolkits and proper scripting, setup, and administration techniques any admin worth their salt would know, and all less taxing on the system.

You seem to fail to realize that systemd is NOT welcome here especially by those of us who understand Linux and what systemd aims to do to Linux that is not needed nor required.

ReaperX7, I didnt know you talked for every single soul here.
you can talk for yourself, but dont talk for others, if they have an opinion they can express that themself.
and there are already some forums post about systemd where that is being done.
and also there you see that there are a few person that want to test and help testing.

Reaper, you don't speak for me, or anyone else here. I don't like systemd either, but if the guy wants to have a topic to discuss with like minded people his attempt to jimmy systemd into a slackware install then he should be allowed to do so without people coming in and disrupting his thread.

Now, if he ever suggests that systemd be adopted by the official Slackware release then I'll grab my torch and pitchfork and be right there beside you, but until then, leave the guys thread alone! I was actually quite curious to see how it progressed.

Testing is one thing but you can't test the system without a complete rebuild first. You'd basically have to fork the system out.

Again you are creating a presumption that all of what you claim will happen is 100% guaranteed. You really should take heed of what AlienBOB told you. No projects have fully committed to systemd and most have left it optional. If those that do make it a had dependency do so, they might as well cut their own throats as not all distributions will adopt systemd like Lennart wants to dream about. Linux and every other flavour of UNIX out there will use what they've always used.

And I don't need to speak for everyone here. Go do a thorough search of systemd topics here and read first.

You really should just fork Slackware as a whole if you want this so badly.

Yes, this. I'm no fan of systemd, but this flame is unwarranted. Our forums should not be a firing ground.

Reaper,

Can you tell me which packages apart from util-linux and dbus needs to be recompiled according to LFS book.

Perhaps now is the time to take GazL's advice and tone it down a notch and just let the OP get on with it. You don't need to keep telling him stuff like this, in such inflammatory ways.

The point of this thread as far as I can tell is to say, "Here are some SlackBuilds to get systemd up and running. How do they work for you? What have I missed?". Let's just stick to that topic.

Working systemd SlackBuilds are handy for three reasons:

1. So that people can try it out and then make informed opinions in the other threads.
2. As a pre-testing ground just in case systemd ever does come to Slack
3. For those who might actually want a Slack-systemd hybrid. Yes, shock, horror, they may actually exist! :p

If none of those hold water for you, just ignore the thread. If others hold your opnion they will ignore it as well and the thread will die a natural death. You don't need to make it your mission to be the top poster in every single systemd thread. I'm pretty certain people already have a vague idea about your opinion on systemd. :D

As a side note, I don't really care about systemd either but I am very grateful to the OP for actually putting the effort in for those who might want to use it or at least test it.

@ruario

thank you

I have very big problem with systemd.Systemd not mount my /usr .My /usr is on separete directory.Systemd not run dhcpcd.
Also when i type my user name or root i've got this

As far as I know, SystemD does not support /usr being a separate filesystem unless you yourself ensure that it gets mounted before SystemD starts (i.e. you need to mount it in the initrd). See http://freedesktop.org/wiki/Software...usr-is-broken/ for a piece of arrogance barfed up by our favourite Slackware destroyer.

Eric

as an old slacker i agree with those that dont want systemd, you cant just build a drop-in replacement of the init system, its like the launch codes on an ICBM multi-warhead nuclear missile = not something to be meddling with if you want it to all work properly

I just want to test it.Why so much hate ?

As far as I know, the separate /usr issue exists right now, even with the glorious and so orthodox udev. This is the price payed to have a super-cool auto-configuration, but having apps or libraries as dependencies in /usr...

That's why most of us we need a properly initrd to boot our super nice auto-configured (and so encrypted?) operating system.

To be honest, even I believe too that the page author is a rare piece of arrogance, still I do not see nothing wrong in that page...

tuxbg,

the error after using your login name is because of the file /etc/login.defs
you will need the one supplied with the package.

most likely it is still /etc/login.defs.new

I updated the build script to make sure it is not .new, people can change the options later as needed.

i think that would work better with an other linux than slackware at the moment.. :)

You are funny guy :)

Yes it was my mistake.I override /etc/login.defs and now all things works

Then, you do not have now any "separate /usr" problems?

No i dont have "any" login problems

good to hear tuxbg,

the next package on my list to do this weekend is util-linux.
this package is linked against libudev.so.0, but systemd/udev since v187 (if not mistaken) is using libudev.so.1

As you see in the systemd.slackbuild it uses currently the ugly hack of linking libudev.so.0 to libudev.so.1
That should at the end not be needed anymore.

If you came across things that might seem to be a problem, do not hesitate to write it here. or send to my mail

Long story short, the SystemD works in your system as expected and you consider that, as replacement (now!) of the orthodox BSD-like init of Slackware, it works equal or even better?

Now, see, most days I don't mind systemd too much, but then they have things like this:

And I think - why not just mount the stuff on fstab first? And who wants to run this stuff before filesystems come up? hplip? Really? Is it a problem that their core init program is linked to all this stuff, and this stuff is on /usr? How about not making the init linked to all this and, after processing fstab, start the bigger part of systemd? Seems easier than changing a 40-something-year-old concept.

But then I read this, and I get it. The word 'Solaris' appears 12 times. Compatibility to other Unixes/Linuxes translates to Solaris. Upstream is Solaris. Despite our closer cousins in BSD, they don't get mentioned once. It's an enterprise move so that Oracle doesn't need to try so hard to port our software.

In the end, if the technical reasons don't make sense, it's because they're made after the fact - it's really about the politics.

But now I'm being mean. I still want to see good stuff come out of these SlackBuilds!

EDIT: Heh, we were still on page 2 when I started that... whoops...

I just wont to test it.What's the problem?Why everybody judge me?

tux, darth-vader wanted to have your opinion.

he wants to know if it works better, the same or worse than before

I do not judge you, my friend! I just ask you if SystemD works fine as replacement of Slackware BSD-Init, which is really it, in our case... ;)

Im sorry.My english is not so good and i dont understend you correctly.Well it works,it boot faster but i cant enable dhcpcd.
systemctl enable dhcpcdt@eth0 doenst work for me

tuxbg

dhcpcd has not been build against systemd yet.
you can just set your /etc/rc.d/rc.inet1.conf to use dhcp

this works.

So here's my version of the 60,000 dollar question.

How is systemd's configuration going to be easier to use than the BSD/SysVInit script set we use that keeps configuration methods, troubleshooting, and managing files written in plain text English, as well as the logging system that performs the same way?

Are you going to create documentation within the configuration files used by systemd to have internal hints, samples, and other documentation about switches and arguments made against the daemons being used?

Will systemd have the ability to support custom daemons not normally added such as is done with rc.local's method of add-on daemons?

ReaperX7: please read post #27 from ruario if not already done.

Can't you see that you are off topic there?

guess what reaperX7, rc.local works

you can add anything in rc.local to start.

also custom daemon are possible yes.

this I have built into systemd file to have the slackware motd work directly

you can have anything start in such a service file.