[pkg-wpa-devel] Re: wpasupplicant experimental branch

[Reinhard Tartler]

On Sun, Mar 26, 2006 at 10:49:29PM +1000, Kel Modderman wrote:
> Recently I have done much work in the experimental branch to create a 
> wpasupplicant package that *I* am happy with. The version sitting in 
> experimental right now is very dodgy, it'd be great to replace it with 
> something with more quality.

What we currently have in svn seems to me very improved!

I just switched my notebook to use this /etc/network/interfaces:

auto ath0
iface ath0 inet dhcp
        wpa-conf /etc/wpa_supplicant.conf
        wpa-action /etc/wpa_supplicant/action.d/dhclient
        wpa-driver madwifi

And now I have a quite nice roaming solution. Thanks to the action
script, roaming should no longer be a problem anymore. If I had some
networks which required manual configuration of interfaces, I could
write my own action script. Great stuff, I love it :)

Just a question, why do you introduced an 'action.d' directory? do you
expect other packages dropping action script in there? Do you intend to
include all files which are dropped there by default?

I think we can install this simple action script to
/usr/share/doc/wpasupplicant/examples/simple-action-script and let the
default configuration choose that. If the user wants a more
sophisticated action script, then he can copy this to this home
directory and edit this to his needs. no problem.

just a glitch: could we please provide some symlinks from
/usr/sbin/wpa_supplicant to /sbin/wpa_supplicant for transitional
purposes? This broke my former home made scripts.

> But I'd really like to here some other opinions about the direction I 
> have taken it, without a bit of criticism (or praise) it cannot improve 
> much from here.
> 
> Some things we would need to consider:-
> 
>    * dropping the init script, ubuntu already has
>    * if we drop the init script, we need some preinst magic to clean up
>      the mess and warn the user
>    * if my interpretation of the ifupdown usage is agreeable to others

Let me summarise the situation how I see it so far:

The traditional solution which involved running wpasupplicant as system
service running all the time is deprecated by the solution we have
currently in experimental. This includes dropping the idea of the init 
script completley in favor of integration with ifupdown. This feels more
natural than anything we had before.

We have currently 2 Problems. One is that we need to revise and update
our current documentation. We need to make sure that a user gets easy
examples for easy cases and outline how he can create more complex
configurations.

The secound problem we have is a well defined upgrade path. The file
/etc/network/interfaces is not a conffile, so we could perhaps try to
detect if the user already used wpasupplicant on one interface (and
which), and then ask via debconf if his /etc/network/interfaces should
be adapted to look like this:

auto eth1
iface eth1 inet dhcp
	wpa-driver wext
	wpa-conf /etc/wpa_supplicant.conf

but since we are talking here about a very sensitive part of system
configuration, we are perhaps better of with writing a high priority
debconf notice that the user should revise his /etc/network/interfaces
with an example and point him to the appropriate documentation, iff we
are actually upgrading. (no need to bug on new installs).

> There are still some things on the TODO list to cut through, documenting 
> interfaces file usage being the highest priority. But before we throw 
> time at that, it needs some exposure/testing.

Experimental seems to be the best place for testing, I think.

The currently prepared upload of wpasupplicant_0.4.8-1 in svn should
perhaps be rethought. It was intended as interim solution only which
should fix some bugs which are currently open in debugs. I didn't expect
that Kels work in experimental would rock that hard that quick. Now we
need to decide where to go from here. I'd love to see the new world
order of wpasupplicant to be uploaded to unstable as soon as possible,
so that we get wider testing as early as possible, to get a good package
for etch!

I propose this for now: Lets upload what we have in experimental now,
and ask more people to test that. In paralell, lets work on the debconf
warning and improve our documentation. When we are happy enough with
that, lets upload that as 0.4.8-1 to unstable, perhaps next weekend.

How does this sound?

Kyle, do you agree with the new approach? Could you please upload what
we currently have in the experimental branch to debian/experimental?

Gruesse,
	Reinhard