In the systemd-love overlay (see URL), I committed a sys-auth/pambase ebuild that removes systemd from IUSE and always enable systemd support. The systemd-love overlay aims at making possible to swap between init systems at runtime, without the need of recompiling packages. All the reverse deps of pambase[systemd] should be fixed, since the USE flag would go away. $ grep -r "pambase.*systemd" */*/*.ebuild gnome-base/gdm/gdm-3.6.2.ebuild: sys-auth/pambase[systemd?] gnome-base/gdm/gdm-3.8.0.ebuild: sys-auth/pambase[consolekit?,systemd?] sys-auth/polkit/polkit-0.110.ebuild: systemd? ( sys-auth/pambase[systemd] ) Reproducible: Always
I believe that the same should be done for pambase[consolekit] though.
Correct, USE="consolekit systemd" shouldn't be there, instead the - should be used to indicate missing module is not fatal. -session optional pam_ck_connector.so nox11 -session optional pam_systemd.so Like done in files/pambase-20120417-systemd.patch already.
However, I'm not sure what happens when both modules are present! Does one break the another? Yet to test systemd that far.
I have pambase[consolekit,systemd] installed on my system and everything is working as it should.
(In reply to comment #4) > I have pambase[consolekit,systemd] installed on my system and everything is > working as it should. You tested with systemd installed, but with OpenRC and ConsoleKit running, that you still get 'active = TRUE' on a text console when you login to tty1? That's the only valid test for it.
(In reply to comment #5) > (In reply to comment #4) > > I have pambase[consolekit,systemd] installed on my system and everything is > > working as it should. > > You tested with systemd installed, but with OpenRC and ConsoleKit running, > that you still get 'active = TRUE' on a text console when you login to tty1? > That's the only valid test for it. with `ck-list-sessions` command on a text console as a normal user, when logged in after OpenRC boot and ConsoleKit on runlevels I mean ...
Yes, I just did that. Installed systemd, USE="consolekit systemd" for every installed pkg, booted with openrc, logged into tty2 and ran ck-list-sessions showing my sessions. All good.
Please CC us on that kind of bugs. And I don't have a strong opinion about this. The use of USE=systemd is valid here. Not sure if apps should actually depend on it though, since installing pambase with or without a flag doesn't guarantee anything really.
CCing gnome team too as probably this "systemd-love overlay approach" will be needed to be able to have logind + openrc properly coexisting for Gnome 3.8
After 10 days in Sabayon repositories, no users have reported issues with my pambase version.
I think we can alternatively just enable the flag by default. That will keep it working for most of our users, and silence the systemd haters.
Yes, I agree. Waiting for a final verdict from pam-bugs@ before proceeding
Fabio what do you think about helping me out with pambase? :P I could use a hand rewriting it..
Feel free to elaborate. What I would like to see in pambase is either a split (so that one doesn't have to recompile pambase all the times, less potential circular deps, more binpkgs friendly) or just drop some of its flags and make the loading of modules non-fatal (for instance, USE=gnome-keyring is sub-optimal because it introduces an important dependency just for avoding a warning if pam_<whatever gnome keyring>.so is not available).
I'd be fine with using optinal for gnome-keyring and the like, the problem is that last I checked if they failed you ended up in a bad situation. If you take a look to the git repository, the new version uses m4 instead of the stupid C preprocessor and allows for a much more fine-grained control on the modules that do get loaded. But it still required rebuilds, and it's sub-optimal. What I'd like would be for pambase to install the templates, and use eselect to enable/disable features, so it uses m4 at eselect time to enable or disable part of the auth chain. Bonus points for allowing modules to install a descriptor file, and have eselect/m4 load these descriptor at runtime to generate the final output. It's overly complex I know, but..
Yeah I think that it would be nice but I am not sure that all that complexity is worth it. The ebuild I use in Sabayon has no USE=gnome-keyring, I enabled it unconditionally and it seems to work, besides the warning...
(In reply to comment #15) > I'd be fine with using optinal for gnome-keyring and the like, the problem > is that last I checked if they failed you ended up in a bad situation. > > If you take a look to the git repository, the new version uses m4 instead of > the stupid C preprocessor and allows for a much more fine-grained control on > the modules that do get loaded. But it still required rebuilds, and it's > sub-optimal. > > What I'd like would be for pambase to install the templates, and use eselect > to enable/disable features, so it uses m4 at eselect time to enable or > disable part of the auth chain. Bonus points for allowing modules to install > a descriptor file, and have eselect/m4 load these descriptor at runtime to > generate the final output. > > It's overly complex I know, but.. It sounds like a nice GSoC project, don't you think? But that'd imply delaying it till the end of summer ;P.
No it doesn't. GSoC projects tend not to become useful for a long time after being proposed.
Any news on this?
After committing that, we need to remember to drop: http://wiki.gentoo.org/wiki/Systemd#systemd-logind_.26_pam_systemd I think
we would need to fix bug 478180 before as it seems some people were hitting some issues when both modules are loaded (but it was long time ago)
please speak up if you see fit for this to be implemented as in my opinion this may exist as it is now (managed via systemd use flag).
