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

[Kel Modderman]

Reinhard Tartler wrote:

>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.
>  
>

That would be a great idea.

>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?
>  
>

If you are referring to current svn trunk, I still have concerns and 
reservations over what has been done to the init script.

Furthermore, the included ifupdown scripts (from ubuntu) are simple 
wrappers to start the same old init script. IMHO, they are not really 
doing anything that is so good that we *must* break compatibility with 
old versions right now.  In fact, my interpretation is that the 
invocation of /etc/init.d/wpasupplicant by these ifupdown hooks is in 
direct violation of Debian Policy 9.3.3 (Interfacing with the initscript 
system):-

    Directly managing the /etc/rc?.d links and directly invoking the
    /etc/init.d/ initscripts should be done only by packages providing
    the initscript subsystem (such as sysv-rc and file-rc).


I'd like to see some quite advanced ifupdown hooks that would allow for 
setting non-standard wpa_supplicant.conf locations (like the config per 
device idea), activating wpa_cli action scripts (in the future, these 
are not so easy to handle), checking for wpa_supplicant processes 
already handling the interface etc etc. I could begin developing the 
skeleton of these ifupdown hooks to see if my idea is valid.

Those are the kind of changes I personally would reserve for the 
experimental branch you mentioned opening.

So, imo the packaging should be cleaned up, updated to the latest 
upstream source from the 0.4.x stable branch but without the current 
radical changes. I'd keep the aging init script for now, and not include 
these ifupdown hooks until they have matured into something more 
intuitive. That would allow time to get something really nice developed 
for an experimental release.

Just my opinion.

Whichever way you go, I'd be glad to be given svn commit rights if you 
think I can bring something good to the project. In fact, you should 
consider opening up the pkg-wpa mailing list for these sorts of 
discussions. I have other points of conversation that are pertinent to 
wpasupplicant's co-existance with madwifi (of which I am joint maintainer).

Thanks, Kel.