[Pkg-wpa-devel] Re: Bug#353530: Several package enhancements,
fixing some flaws in maintainer scripts
Mon Feb 20 23:11:37 UTC 2006
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
More information about the Pkg-wpa-devel
mailing list