[pkg-wpa-devel] Proposal: Split the package

[Reinhard Tartler]

On Tue, Apr 11, 2006 at 10:29:59AM +0200, Felix Homann wrote:
> as you have probably seen bug #360387 has been reopened. 
I've noticed that, and I'm concerned about that.

> For users of Debian/Sid the way the new mode of operation was 
> introduced might be acceptable, but what's going to happen when your someday 
> upgrading from Stable?

This is a valid point. And I'd really love a different solution than
adding a priority low debconf question about that, which get's
autodetected based on the upgrade path, because this creates new
unnecessary cornercases. I'm much for keeping the packaging simple and
maintainable.

> Is there any possible usage scenario of wpasupplicant that got not broken by 
> the upgrade? That should not happen!
> 
> Furthermore, there seem to be setups that still can't be reworked with the new 
> approach, or not in an easy manner.
> 
> Therfore, I would suggest the following:
> 
> 1. Split the package into
> 
> 	a. wpasupplicant-base: Essentially containing only what upstream delivers
> 	b. wpasupplicant-ifupdown-plugin: Everything needed for the new modes
> 	c. wpasupplicant-init-script: The init script, the old stuff
> 
> 2. Turn wpasupplicant into a meta-package 

I think this split causes unnecessary bloat of the debian dependency
tree, and I'm quite sure that this would be rejected by our ftp-masters.
Whats the point of packaging /etc/wpa_supplicant/ifupdown.sh in a binary
package of its own? I mean it isn't enabled by default anyway.

Anyway, you are suggesting something which I suggested in another form
already on this list: Package a real roaming daemon/solution, which can control 
ifupdown, wpasupplicant and perhaps ifplugdown.

How about a new package, lets call it wireless-roaming-daemon, which
depends on wpasupplicant, guessnet and perhaps ifplugd, which installs
an init script and provides an easy to use interface to the user to
configure his locations? It would then start wpasupplicant and control
ifupdown just as before. (we can still decide if this solution should go
into the wpasupplicant source and/or binary package or into a source
package of its own). 

The initscript itself isn't a roaming solution at all. You can easily
install it yourself, and compared with the efford you have to take in
integrating it with ifplugd and guessnet, this is the easiest task. So
IMO, you are complaining at the wrong place.

> This can suggest wpasupplicant-ifupdown-plugin. On upgrades it can ask people 
> to either install wpasupplicant-init-script to keep the old setup or to 
> switch to the new approach via wpasupplicant-ifupdown-plugin (which by then 
> should include an upgrade guide).

I'm rather for adding a note in the etch release notes about this
upgrade.

Gruesse,
	Reinhard