[blfs-support] Polkit Actions

Bruce Dubbs bruce.dubbs at gmail.com
Thu Dec 12 19:42:29 PST 2013

Armin K. wrote:
> On 12/12/2013 11:14 PM, Dan McGhee wrote:
>> On 12/12/2013 03:17 PM, akhiezer wrote:
>>>> Date: Thu, 12 Dec 2013 12:37:39 -0600
>>>> From: Dan McGhee <beesnees at grm.net>
>>>> To: BLFS Support List <blfs-support at linuxfromscratch.org>
>>>> Subject: Re: [blfs-support] Polkit Actions
>>> 	.
>>> 	.
>>>> I usually don't suggest things like this and I don't know if ConsoleKit
>>>> can be used without PAM. [...]
>>> It can be used ohne PAM: Slackware does not use PAM, and does use (optionally)
>>> console-kit; ref e.g.
>>> --
>>> * ftp://ftp.slackware.no/slackware/slackware64-14.1/source/l/ConsoleKit/
>>> * ftp://ftp.slackware.no/slackware/slackware64-14.1/source/l/ConsoleKit/ConsoleKit.SlackBuild
>>> --
>>>> [...] But in some of the pacakge pages there are
>>>> comments like "If you don't install the optional dependencies then you
>>>> can't do <description>. Armin said yesterday that PAM was almost a
>>>> required dependency of ConsoleKit. Maybe a comment of explanation would
>>>> be appropriate for the ConsoleKit page.
>>> 'almost' !== 'required'  (of course).
>>> Hopefully BLFS will continue the recent-years move towards the practice of
>>> being (more) rigourous, consistent, strict and correct, about the meanings
>>> of 'Required', 'Recommended', 'Optional', and their variants. In other parts
>>> of Linux, there's been far too much - to put it lightly - forcing of
>>> contrived dependencies: so I'd hope it doesn't begin to appear in
>>> (B/)Lennux From Scratch also.
>> I agree with you 100%. And this is why I hesitate to make suggestions
>> like I did.
>> When something does not work for me, the situation is usually that I
>> missed something in the book's instructions or I didn't have the
>> knowledge to make it work in the first place. This was the case with the
>> console kit, gnome-polkit, polkit, xfce4 combination that I wanted to
>> configure. And in my latest situation, it was console-kit that was not
>> "helping." I know I would not have had the problem if I had installed
>> KDE, but I chose XFCE4 and had to work on the configuration myself.
>> My knowledge, or, as in this case, the lack of it is usually the
>> culprit. Even after the last couple of days I have only a foggy notion
>> of how all those applications fit together and work. The piece of
>> knowledge that ConsoleKit needs PAM to generate an active session solved
>> my problem.
>> Now is it the entire set of PAM modules? I don't know. I don't even know
>> if having only one PAM module will do the trick. I found it interesting
>> in examining one of the links you provided that I found these lines in
>> slack's install script for ConsoleKit:
>>> cat $CWD/pam-foreground-compat.ck > \
>>>     $PKG/usr/lib/ConsoleKit/run-session.d/pam-foreground-compat.ck
>>> chmod 0755 $PKG/usr/lib/ConsoleKit/run-session.d/pam-foreground-compat.ck
>> That file pam-foreground-compat.ck is built and installed in ConsoleKit.
>> Can it be used without the rest of PAM? If slack doesn't install PAM,
>> the answer is yes. But, how then do you configure ConsoleKit to work
>> properly. It didn't in my install.
>> It may not be precise or technically correct, but installing PAM helped
>> my system to work. Is it then a "run time" dependency? Maybe you could
>> call it that.
> No, it's a build and runtime dependency. You need PAM headers and libs
> to build pam_consolekit.so PAM module, which in turn is responsible
> (using PAM session facility) to register a local session with
> ConsoleKit. Same mechanism is used by systemd-logind, which uses
> pam_systemd.so to register sessions.
>> This is the logic that I used when I wrote what I did. I figure that if
>> I don't find anything in the archives, then I'm the only one who's
>> having the problems, or, at least, I'm the only on who is asking. That's
>> not a basis for suggesting a change or addition to the book.
> Believe me, you are not the only one who has this specific problem. I
> lost a count of these people. We have a policy that we can mark required
> packages only if the package can't be built without it. Recommended
> packages are ones which are essential, but package can be built without
> them. We do expect that recommended dependencies are honored. Optional
> dependencies are what you think they are. You can or can't install them,
> your choice. You might be missing some specific (and not so common)
> funcionality, but you can always reinstall package later with specific
> feature enabled.

We've always allowed extra information in the form of text or a note. 
It sounds like this is needed here.

   -- Bruce

More information about the blfs-support mailing list