Should I proceed with removing systemd related files from sys-auth/consolekit since they are not supposed to be used in favor of the systemd-logind? Such as /usr/lib/systemd/system/console-kit-daemon.service /usr/lib/systemd/system/console-kit-log-system-start.service /usr/lib/systemd/system/console-kit-log-system-stop.service /usr/lib/systemd/system/console-kit-log-system-restart.service /usr/lib/systemd/system/basic.target.wants/console-kit-log-system-start.service /usr/lib/systemd/system/halt.target.wants/console-kit-log-system-stop.service /usr/lib/systemd/system/poweroff.target.wants/console-kit-log-system-stop.service /usr/lib/systemd/system/reboot.target.wants/console-kit-log-system-restart.service /usr/lib/systemd/system/kexec.target.wants/console-kit-log-system-restart.service
So... are you ready to let ConsoleKit go in favour of systemd-logind? People keep coming to me about it.
There is still software which does not support the new systemd-logind interfaces. KDE, for example. https://bugs.gentoo.org/show_bug.cgi?id=451954 To be honest, I'm a bit clueless when it comes to this session tracking stuff; is there any harm in installing the service files if the user chooses to keep consolekit on their system?
Thanks for the answer, you are right, this one should depend on bug 451954 (and on my work for getting systemd-logind support to xfce-base/xfce4-session which basically only needs testing at this point, I'm working on getting USE="logind" to sys-fs/udev so non-systemd users can use it too)
> I'm working on getting USE="logind" to sys-fs/udev so non-systemd users can > use it too) I made a prototype to get rid of systemd prefix and add logind to udev ebuild. It compiles well and logind doesn't need system-daemon library but I never had time to test it. I'm working on a mdev.conf substitute ;) Also the ebuild is /var/run compatible. If you wan't you can try it. See attachement.
Created attachment 344502 [details, diff] udev 200 diff
Created attachment 344504 [details, diff] udev-198-logind.patch
Created attachment 344506 [details, diff] udev-198-nosystemd-daemon-makefile.patch
Created attachment 344508 [details, diff] another unfinished patch from yesterday
i'm trying to get this working in a way we don't have to patch it at all, if that means shipping the libsystemd-daemon library again with USE=logind, i'd rather do that btw, your patch seems to do more than just add logind support, adds back now removed stuff like sep. /usr warning which belongs to the systemd's ebuild if anywhere (bug 463386) and more but I guess that's why you said it's a prototype ;)
(In reply to comment #8) > Created attachment 344508 [details, diff] [details, diff] > another unfinished patch from yesterday Thinking about it a bit more, as openrc and systemd are parallel installable, maybe it doesn't deserve the effort to make udev ebuild provide more systemd pieces and would be better to simply move to systemd ebuild :|
(In reply to comment #10) > (In reply to comment #8) > > Created attachment 344508 [details, diff] [details, diff] [details, diff] > > another unfinished patch from yesterday > > Thinking about it a bit more, as openrc and systemd are parallel > installable, maybe it doesn't deserve the effort to make udev ebuild provide > more systemd pieces and would be better to simply move to systemd ebuild :| Quoting: """ Systemd is bad bad bad component for open source efforts, especially when we have much simpler well behaved OpenRC which provides a great service! I don't want to see any leftover at my system that belongs to a component I do not use nor intend to use. """ I don't know about you but I already see those people marching out of Gentoo because we made them install systemd!
I don't have a strong opinion on this. Personally, I want to keep running openrc, if installing systemd doesn't impose me to run systemd (that looks the case), then, installing systemd stuff doesn't hurt me (I guess it won't require a lot of disk space :P) I tried to install systemd to solve the Gnome 3.8 problems some weeks ago, but finally didn't because it requires to uninstall udev ebuild and I preferred to keep using "official downstream" udev because I want to only run "stable" udev (I mean, I want to be sure once I switch to udev provided by systemd ebuild, I can run the same stable version as udev ebuild for the same time, without needing to start updating to systemd-203, 204, 205...)
All this problems could be probably solved by splitting systemd in several parts: a systemd-common ebuild (for files shared between different components), udev, logind... and a systemd meta ebuild installing all components. But that is probably too much effort. Other option could be to add some "minimal" USE flag to systemd ebuild for people not needing to RUN systemd (that would provide components that can be used with openrc running => udev and logind for now)
(In reply to comment #13) > All this problems could be probably solved by splitting systemd in several > parts: a systemd-common ebuild (for files shared between different > components), udev, logind... and a systemd meta ebuild installing all > components. But that is probably too much effort. > > Other option could be to add some "minimal" USE flag to systemd ebuild for > people not needing to RUN systemd (that would provide components that can be > used with openrc running => udev and logind for now) The problem is that upstream doesn't want to do that. Anything we do ends up being a huge hack. USE=minimal would mean not only a huge hack but basically the two different ebuilds switched by a big 'if use' inside.
I would go for the simplest solution, which has been also adopted by Ubuntu: move logind to a separate ebuild, make systemd depend on it, replace consolekit with logind, drop consolekit. logind is a very small piece of systemd. By the way and FYI, in Sabayon we moved to systemd and we use it as device manager when openrc is booting the system. Upstreams are forcing us to adopt systemd, like it or not. Adopting logind, while being the only sane option I can see, it just a way to postpone the date in where we'll run into a "systemd or die" situation. And if you haven't realized it yet, we already started writing more and more code to mimic systemd functionalities on openrc...
Last time I reviewed ubuntu, they simply relied on systemd for logind support, I saw no splitting :/
Huh, that's what they told me :/
One other thing that should be considered ASAP is potentially changing USE=systemd used purely for logind to USE=logind. Not sure if there aren't services which switch logind+other systemd stuff with a single option.
Created attachment 347524 [details, diff] from udev-200.diff to 202
hello, Off topic. I still use /var/run instead /run and it works great. /var and /usr are mounted outside initramfs in case it gets corrupt or needs to be restore. I don't use openrc or systemd either. De facto, I prefer openrc. Also, /run is hardcoded in most portage ebuilds like cups postgres etc. It would be great to add an environment variable RUNDIR= usable in make.conf to give more choice to the user like ... myself. Thx
(In reply to comment #20) > Also, /run is hardcoded in most portage ebuilds like cups postgres etc. It > would be great to add an environment variable RUNDIR= usable in make.conf to > give more choice to the user like ... myself. This is not necessary because /var/run is now a symbolic link to /run. Thanks, William
(In reply to comment #21) > (In reply to comment #20) > > Also, /run is hardcoded in most portage ebuilds like cups postgres etc. It > > would be great to add an environment variable RUNDIR= usable in make.conf to > > give more choice to the user like ... myself. > > This is not necessary because /var/run is now a symbolic link to /run. > > Thanks, > > William Not everyone use links or tmpfs mount points. For heaven sake's, why not add a shell variable to handle run directory ? It would be really easy to implement. Moreover, it is like EROOT, EPREFIX, ROOT, PORTDIR, HOME, XDG_RUNTIME_DIR family variables. Also, not necessary doesn't mean not doable or useful. Please, let Gentoo more neutral.
(In reply to comment #22) > (In reply to comment #21) > > (In reply to comment #20) > > > Also, /run is hardcoded in most portage ebuilds like cups postgres etc. It > > > would be great to add an environment variable RUNDIR= usable in make.conf to > > > give more choice to the user like ... myself. > > > > This is not necessary because /var/run is now a symbolic link to /run. > > > > Thanks, > > > > William > > Not everyone use links or tmpfs mount points. Misconfigured systems then. > For heaven sake's, why not add a shell variable to handle run directory ? It > would be really easy to implement. Because run directory needs to be in / and not in /var for eg. bug 416081 And there are more > Moreover, it is like EROOT, EPREFIX, ROOT, PORTDIR, HOME, XDG_RUNTIME_DIR > family variables. > > Also, not necessary doesn't mean not doable or useful. Please, let Gentoo > more neutral. /run should be directory with tmpfs, /var/run should be a symlink to it
(In reply to comment #23) > (In reply to comment #22) > > (In reply to comment #21) > > > (In reply to comment #20) > > > > Also, /run is hardcoded in most portage ebuilds like cups postgres etc. It > > > > would be great to add an environment variable RUNDIR= usable in make.conf to > > > > give more choice to the user like ... myself. > > > > > > This is not necessary because /var/run is now a symbolic link to /run. > > > > > > Thanks, > > > > > > William > > > > Not everyone use links or tmpfs mount points. > > Misconfigured systems then. > > > For heaven sake's, why not add a shell variable to handle run directory ? It > > would be really easy to implement. > > Because run directory needs to be in / and not in /var for eg. bug 416081 > And there are more > > > Moreover, it is like EROOT, EPREFIX, ROOT, PORTDIR, HOME, XDG_RUNTIME_DIR > > family variables. > > > > Also, not necessary doesn't mean not doable or useful. Please, let Gentoo > > more neutral. > > /run should be directory with tmpfs, /var/run should be a symlink to it You contribute a lot to gentoo, so I don't want a fight with you, but you reinvent *nix. :) Anyway I respect your point of view, but it would make my work easier to have the choice. Please don't stay subborn. Your last sentence say 'should' not 'have to'. Is it still hope then ? ;)
(In reply to comment #24) This bug is not the place to have this discussion. I suggest the gentoo-dev mailing list as a good alternative.
I really can't wait to have this issue sorted :-) Is there anything else blocking this? Not that we have many alternatives (this or a logind ebuild... and both suck a bit).
CCing udev maintainers as the plan looked to be the addition of logind support to udev ebuild
Created attachment 348482 [details, diff] USE="logind" Only tested that builds once or twice. Manpages missing.
Any news on this? This is the main blocker for Gnome 3.8, I have seen some work in systemd-love overlay but in a different direction -> let systemd ebuild provide the logind init.d script
Created attachment 350142 [details, diff] Required patch for standalone logind Something like this needs to be done for logind itself to work without systemd
(In reply to Pacho Ramos from comment #29) > Any news on this? This is the main blocker for Gnome 3.8, I have seen some > work in systemd-love overlay but in a different direction -> let systemd > ebuild provide the logind init.d script I've stabbed it again half an hour to hour, resulting in Comment #30 and even more messier ebuild than Comment #28 Once you get the required bits built with patch from Comment #30, it'll work, but I'm propably giving up entirely, the more I write to the ebuild the more unreadable it becomes, this isn't something I'm intrested in maintaining since Xfce won't drop ConsoleKit support
And this bug was originally about dropping systemd related files from ConsoleKit which I'll do later and don't need this bug for it Somehow it diverged into this beast, file a new bug like 'sys-auth/logind: new package' or 'sys-fs/udev: introduce USE=logind' for the purpose
Comment on attachment 348482 [details, diff] USE="logind" Obsoleting attachment, it can't be this ugly
