Bug#412179: [pkg-wpa-devel] Bug#412179: D-Bus interface

[Kel Modderman]

On Monday 05 March 2007 18:57, Michael Biebl wrote:
<snip>
> > To suggest an answer to my pesky questions above, would could ship a
> > conffile similar to this now, but disabled, and when networkmanager 0.7.X
> > is in the archive "flip the switch" and upload new wpasupplicant with
> > conffile set to activate wpa_supplicant dbus daemon by default.
>
> Yeah, this would be one possibility and I had something like this in my
> mind initially. We'd just have to coordinate the releases somehow when
> NM 0.7 is officially released (maybe a versioned dependency on
> wpasupplicant with the switch on would be an option).

Yep, this is what I understood so far.

>
> Another possible solution I see, is to ship the dbus related files
> (/etc/dbus-1/event.d/*, /etc/dbus-1/system.d/* and
> /usr/share/dbus-1/services/) in a separate package, let's call it
> wpasupplicant-dbus, and network-manager 0.7 would then depend on this
> package.

I started thinking this way this morning too.

> The question is, if a separate package for 3 small text files is justified.

Method #1 - system daemon via wpasupplicant
##############################
Pros:

Save going through NEW again.

No need to maintain another, pretty damn small binary package.

Cons:

Cannot ensure that the wpa_supplicant dbus aware system daemon is started upon 
installation of an app that needs it, we can do our best with co-ordination 
of package uploads.

Once an app that needs wpa_supplicant's dbus interface is in the debian 
archive, we are faced with the situation where we must enable the system 
daemon always, regardless of whether or not such an app is actually 
installed, or force the admin to activate it via conffile after watching the 
app that needs it fail spectacuarly.

Method #2 - system daemon via wpasupplicant-dbus
#################################
Pros:

Any app that needs wpa_supplicant's dbus interface can be sure this package, 
wpasupplicant-dbus, enables that functionality unconditionally.

We avoid having to start the daemon always even though not one single package 
on the system requires that, in the off chance the admin may install a 
package that does.

We don't need to edit a conffile to disable the system daemon.

pkg-wpa and pkg-utopia don't have to co-ordinate uploads so tightly.

Cons:

We must maintain and provide a tiny package.

Package must go through NEW again.

################################

My opinion; I tend to lean towards providing the seperate binary package, 
wpasupplicant-dbus, even though it would be tiny. The benefits seem to 
overwhelme the old package maintainance adage of not splitting out code if it 
is sufficiently small.

Thanks, Kel.