I'm really sorry to hear that you'll be leaving us. None of us on the Adelie team are happy about the ConsleKit2 and elogind situation either. I led the most recent push to abandon ConsoleKit2 and I will personally be taking responsibility for this situation moving forward. Unfortunately, none of the options we had here were good. Our first option was to just keep using ConsoleKit2. But this is just no longer feasible for us. Most upstream developers who were using it have switched to logind's interfaces, so someone has to patch upstream code to support ConsoleKit2. Gentoo decided to abandon ConsoleKit2, and Gentoo was the largest Linux distribution in both user base and developer base that was still using ConsoleKit2. So Gentoo abandoning it meant that the largest base of potential contributors had vanished, which means that we would need to take on that responsibility if we wanted to continue using ConsoleKit2. But Adelie only has about 5 core contributors, of which only 1 can work on Adelie more-or-less full time. And we already have to spend too much of the limited time we can devote to package maintenance on other issues. Supporting musl very frequently requires us to patch code, and it requires us to test things thoroughly to detect potential breakage. Supporting big endian systems like PPC32 and PPC64, also requires a huge amount of effort -- you do not want to know how painful it is for us to patch firefox's rendering code every time a new release comes out. If we had more developers who could commit time to maintaining ConsoleKit2 and support for it, then we would continue to support it and commit to not having elogind. Our second option was to just remove ConsoleKit2 and patch out the few places that want (e)logind or ConsoleKit2. That patching would still take significant development resources that we don't have. Worse, this would prevent power management functionality from working in desktop environments. One of Adelie's biggest goals is to produce a desktop system that anyone can use regardless of how much or how little experience they have with Linux. Not having working power management in a desktop would at best look like a lack of functionality and at worst look like a bug, and software must work. So this wasn't an attractive option to us either. Third, we could have made our own replacement for elogind. But this would have required even more development time than the other options, so this is just not an option. Ultimately, we have to keep up with what our primary goals are: POSIX® compliance, compatibility with a wide variety of computers, and ease of use without sacrificing features, with minimal hardware requirements, truly libre software, and standards compliance. There is nothing in those goals that says we must avoid using elogind or even systemd. Arguably, the "without sacrificing features" and "standards compliance" goals say we should be using elogind. As for the concerns about systemd, there is absolutely nobody in the core team who would support switching to systemd as an init system or even offering it as an option. Our long term plan is to support s6 and OpenRC, and this will not change for as long as I am involved in this project. I would also like to address some of the points you rose in your message: On 25/07/2020 05:54, Fungi4All wrote: > I heard the justification that elogind was a good thing because we need wayland. The decision had nothing to do with wayland. There are other issues that have been slowing its adoption not just on Adelie but on other distros, and ConsoleKit2 was not one of them. > What I am afraid will happen is not whether those who really need elogind will get elogind, but much of the stuff that doesn't really need it will also get it, forcing people like myself to have it because stuff stopped working. These are the only packages that reference it as a dependency: - bluez, though it's a notoriously bad piece of software anyway - kscreenlocker, which needs it for managing access to the console - plasma-desktop - polkit - networkmanager, which only uses it for session and suspend tracking, and I think can work without elogind - sddm, which is KDE's preferred login manager, but totally optional if you want to run KDE. As far as I can tell, they only need the dependency because of shared libraries, and will still mostly work at runtime without elogind running. As of right now, elogind is not enabled by default. > And would stuff that need elogind work without having dbus? So dbus must be working for elogind to work so that other stuff will work as well. You would still need to have dbus running, but it's far from the only thing that needs dbus. And, again, elogind is only needed for limited things like power management, session switching, and some screen lockers. There are screen lockers like i3lock that don't require it, and things like the shutdown command will work with sysvinit or s6-linux-init without needing elogind or dbus. > So the trojan horse comes in layers. As long as the excuse that pid1 is not systemd we can be perceived as rebels. That is what devuan said, artix since day 1, and void much later, ataraxia, alpine, ... I think this only leaves Kiss-Linux out with the specific commitment to "not expect elogind ever to appear on the repositories" > https://k1ss.org/software#3.0 > and of course Obarun last but not least. elogind is forked from systemd, and it's the only systemd daemon that we will use, and even then it's just a fallback until a better option becomes more feasible. We are still committing to not using systemd as PID 1, not using systemd-journald, not using systemd-networkd, not using systemd-homed, not using systemd-machined, not using systemd-timesyncd, etc. > "But what is a distro to do, we can't rewrite and fork all upstream desktop stuff" > > Drop Gnome from the repository, if you are supporting. If not, now you could! > KDE works on top of this hollier than crap QT platform, and elogind has penetrated right through this layer through dependent software and now plasma does not work without it. It does seem to work fine in obarun. > So drop KDE plasma, or at least any particular pieces of software that need it. There are choices. "[E]ase of use without sacrificing features" is one of our core principles, and so is giving people a real choice in what desktop environments they use. We can't just refuse to provide desktop environments because we don't like one piece of software that they interact with. Doing so would be even more hostile to users than supporting elogind. > But getting xfce4 applications to work with elogind and need it when they didn't upstream to me is a breach of contract. I'm not sure what you mean by this, but we will not make things depend on elogind that don't depend on logind upstream. There's just no good reason to do that, and it would be a waste of everyone's time. > I should have known 2 years ago when I first installed adelie and noticed that pretty much anything LXDE related was absent but LXQT buggy stuff was everywhere. So ultimate stability LXDE/XFCE4 was not a priority but lxqt and plasma were. That should have been a good indicator of where this was heading to. There are people on the team who use Plasma and XFCE now. I don't remember what the situation with XFCE was back in 2018. There are some other window managers we maintain too. If we had contributors who could maintain additional desktops, then we would have them and support them at the same level as other desktops.

To become root, open a Terminal window (such as Konsole or QTerminal) and run "su", then enter your root / administrative passphrase.