Updates in svn

[Kel Modderman]

Loïc Minier wrote:
>         Hi,
>
> On Wed, Mar 29, 2006, Kel Modderman wrote:
>   
>> I prepared the package in the experimental branch of our svn archive.
>>     
>
>  Hmm, I've found it in notuploaded/, and I moved it to experimental/
>  (after removing an empty madwifi/debian tree).  Perhaps your svn mv
>  failed?
>    This move is necessarily disruptive, if you had anything unchecked in
>  your private copies, you'll have to merge it by hand with the move.
>   

Apologies,  just a day or so before I decided that it would be best if 
you populated the experimental branch personally, so I removed the stuff 
prepared there a couple of weeks ago.

Many thanks for the upload!

>  I've uploaded the package to experimental, and I'm now using the
>  modules with unstbale's wpasupplicant in -D wext mode.
>   

Pretty cool huh? :-)
>  I didn't change anything else because I wanted your name to appear in
>  the upload (you did all the work after all), here are a couple of
>  remarks:
>  - the madwifi-ng-dev package is useless for most packages in Debian:
>    since packages which could build against it such as wpasupplicant are
>    in main, it is not possible for them to build against packages in
>    non-free
>   

That was provided for convenience of the end user: to compile their own 
hostapd/wpa_supplicant binaries against exactly that madwifi source version.

If you do not like it, say so, and it will disappear.

>  - there's no upgrade path for people with current madwifi-source or
>    madwifi-tools packages installed (that is aptitude update && aptitude
>    upgrade won't pull madwifi-ng-source)
>   

Yes.

>  - the Conflicts are not necessary, Replaces are enough (yeah this is
>    weird, but it makes upgrades easier, and downgrades harder, and is
>    really recommended for the sanity of apt)
>   

Ok.

>  This issues will have to be worked out before uploading to unstable,
>  but there's a fundamental naming choice to settle on first: how will
>  binary packages be named in Debian unstable after the switch?
>    Because I'm not sure of the output this decision, I uploaded the
>  madwifi-ng source (in a madwifi source package) to experimental with
>  the new names for binary packages (this is because of the new binary
>  packages, the source will be stuck in NEW for a while).
>    But is it really useful to rename madwifi-* packages to madwifi-ng-*
>  packages?
>   

Until the madwifi code is considered complete by ourselves and the 
madwifi developers, I'd suggest that it should only be available in the 
experimental repo, and the madwifi-ng name should remain intact until 
then so that the user must make the conscious decision to install and 
use them.

>    IMO, it's at least as complicated (if not more) to handle a
>  transition from madwifi-* packages to madwifi-ng-*, than to make a
>  transition from madwifi-ng-* packages to madwifi-* packages in the
>  distributions already using the madiwif-ng-* binary packages.
>    Here a couple of reasons why I think madwifi-* names are preferable
>  for Debian unstable and/or in general:
>  - this would make the upgrade in Debian unstable and probably some
>    other distros easier (no transitional packages to keep around until
>    the next Debian stable release)
>  - the current pacakges are not called madwifi-old :)
>  - "ng" doesn't mean anything to end users, it would make sense if we
>    were keeping a madwifi source package with madwifi-old sources
>    parallel installable with madwifi-ng
>
>  But perhaps I miss some arguments on advantages of madwifi-ng-* binary
>  packages.
>   

I absolute agree with everything you say. As above, we should make that 
change when the sources are tagged as "stable enough for distribution 
use" by upstream (or we collectively make this decision ourselves). Only 
then, should we rename the binaries to madwifi-* and upload to any 
branch != experimental.

I don't really want to introduce the new code until after etch, and I 
can't see the outstanding issues in madwifi-ng being fixed completely by 
then anyway.

Is this reasonable enough?

>
>  On a completely unrelated note, I used to have two interfaces handled
>  by the driver: ath0 and ath1, ath0 being the builtin atheros of my
>  thinkpad (802.11b) and ath1 the PCMCIA card (Netgear WG511T).  I now
>  have only wifi0 and ath0 (which are IIUC the control interface and the
>  managed virtual interface of the PCMCIA card), is this is a regression?
>  lspci:
>  0000:02:02.0 Ethernet controller: Atheros Communications, Inc. AR5211
>  802.11ab NIC (rev 01)
>  0000:03:00.0 Ethernet controller: Atheros Communications, Inc. AR5212
>  802.11abg NIC (rev 01)
>  The driver claims support for AR5211 in my dmesg output.
>
>  

Yes, if both devices are not detected and used by madwifi, it is 
definitely a regression. Until very recently I had a similar setup 
without problems. I may need to replace the internal ipw2200 mini-pci to 
test this again . . .

Thanks, Kel.