On Wed, 2008-10-08 at 18:01 +0200, Michael Biebl wrote: > This is known issue. > I already discussed this with davidz quite some time ago (I noticed it > when I tried to enable the policykit support in consolekit). > There were also quite lengthy discussion about this topic on the hal > mailing list about circular dependencies between CK and PK.
Thanks, I wasn't aware that this topic had been dicussed. I'm aware of the discussion over the circular dependency, and I agree with you. > We couldn't agree on a acceptable solution yet. > Some ideas floating around, were: > a.) ship PolicyKit.conf in libpolkit2. Imo a no-go, as it would make > future library transitions painful (libpolkit2 and libpolkit3 wouldn't > be co-installable) > b.) Create the config file in libpolkit2.postinst. Would be quite > hackish, and we'd have to move the user creation into > libpolkit2.postinst, so we can successfully chown the file. > c.) Move the *single* conf file into a separate package > libpolkit-common. Quite some overhead > d.) Do nothing within libpolkit2. Other software should gracefully > handle the case, when polkit_context_init fails. > e.) Change polkit_context_init to not fail if PolicyKit.conf is not > present. Don't think this is a good idea. Can I ask why not e? As I point out in the upstream bug the non-existance of the file isn't fatal when it is read to determine the settings, so unless it is relying on the calling code stopping after polkit_context_init failure it allows an empty file. Just to clarify, the problem also applies to the policy dir and the PolicyKit.reload file. Thanks, James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
