[Pkg-wpa-devel] Re: Bug#353530: Several package enhancements, fixing some flaws in maintainer scripts

On Mon, Feb 20, 2006 at 02:02:35PM -0800, crimsun at fungus.sh.nu wrote:
> I'm not convinced that breaking existing systems is the right way to do
> things in the short run. Yes, we need to migrate from the initscript
> eventually, but we'll end up re-rolling much of its functionality into
> whatever we do. Current our ifupdown scheme is the right way for new
> wpasupplicant installations, and existing installs will continue to
> work (though the ifupdown scheme will simply be redundant for users who
> have manually modified /etc/network/interfaces).
> 
> Obviously we all need to discuss the far-term migration path. Open
> issues:
> (1) Handling multiple wireless interfaces. Currently the method is
> crude; we parse /etc/default/wpasupplicant.
> (2) Packaging 0_5 branch versions instead of 0_4. This will be strongly
> influenced by Etch's release date. I'm not in favour of dropping 0_5
> packages into Debian's next stable release; how do you guys feel?

How about packaging 0_5 in a separate svn branch, and eventually upload
that to experimental? This way we can experiment with dropping
/etc/init.d/wpasupplicant and testing upgrade paths as well. If it turns
out that the 0_5 gets mature enough for releasing with etch, so be it.
If not, we can still think about 'backporting' packaging improvements
like debconf for preconfiguring WPA-PSK and such.

I will see how I have time the next days to open and work on a 0_5
branch.

Daniel, Kel, are there still issues in the current svn? Do you think it
is ready for upload?
 
> One issue from reading BTS would be the need to preseed RSN/WPA with
> the "proto" directive (#340291).

I have the impression that this results from a bug in the driver. If we
want to workaround it, we should rather do that in the wpasupplicant
binary than in the config file. 

Gruesse,
	Reinhard