hal -> udev migration for libgphoto2

[Kay Sievers]

On Thu, Jun 4, 2009 at 17:21, David Zeuthen <david at fubar.dk> wrote:
> On Thu, 2009-06-04 at 16:14 +0200, Martin Pitt wrote:
>> I wrote a first patch against libgphoto2 to add a new "udev 136" mode
>> to print-camera-list. Patch and details on
>>
>> https://sourceforge.net/tracker/?func=detail&aid=2801117&group_id=8874&atid=308874
>
> This looks good. But how about setting ID_GPHOTO2=1 instead of hoping
> that we'll always set GPHOTO2_DRIVER? Not important I guess, just think
> it's nicer that way...
>
>> # mark for automatic ACL management
>> ENV{GPHOTO2_DRIVER}=="?*", ENV{ACL_MANAGE}="1"
>
> This probably shouldn't be in gphoto2 but in udev-extras instead
> (separate policy from mechanism and allows us to change how ACLs are
> handled in the future). Kay, what do you think?

The ACL_MANAGE trigger should be in udev only and not in the gphoto
rules, it's udev "policy stuff" which should not leak into generic
infrastructure. We do the same for scanners already in the udev acl
rules:
  ENV{libsane_matched}=="yes", ENV{ACL_MANAGE}="1"

>> Questions, comments? David, do you see anything missing for a gvfs gphoto
>> conversion to libudev?
>
> Nope, this looks good if we do ID_GPHOTO2 and nuke where ACL_MANAGE is
> set. For implementation: we want GVfs to try using libgudev-1.0 first,
> if that's not available fall back to using HAL (to avoid breaking
> old/current Linux and FreeBSD and Solaris).

Sounds all good to me.

Thanks,
Kay