[Pkg-utopia-maintainers] Bug#919619: Bug#919619: NM 1.24.0 now has basic support for hidden networks with iwd backend

Sun Jul 12 19:16:25 BST 2020

Quoting Andreas Henriksson (2020-07-12 18:40:57)
> On Sun, Jul 12, 2020 at 05:39:19PM +0200, Jonas Smedegaard wrote:
> > I understand that neither you nor Andreas consider current release of 
> > IWD a _recommended_ alternative for wpa-supplicant.  That is a good 
> > reason to not depend on or recommend iwd.
> 
> I think iwd itself (since >= 1.2, so not the version in buster) has 
> reached production quality. The problem here is the iwd backend in 
> *NM* which is not production quality and actively discuraged by NM 
> upstream!

Thanks for the clarification: Yes, I meant iwd used with network-manager 
which this bugreport is about (not IWD in general).

> Please note that the iwd backend is not even *compiled* by default! 

Ok, but doesn't really change my point: You and network-manager upstream 
really REALLY not recommending iwd as alternative for wpa-supplicant 
does not change that network-manager is usable without wpa-supplicant.

> > I do not understand, however, why you will not relax relationship on 
> > wpa-supplicant to recommend it instead of depending on it.
> 
> Because there's no benefit in doing it, while there's a massive 
> support burden. There's a massive amount of clueless users who 
> blatantly configure recommends to not be installed and any application 
> that has as many users as NM will be hit with a floodwave of support 
> requests over it. From being involved in the GNOME team we know it's 
> simply not possible. You haven't offered to do the work, but if you're 
> willing then start out by triaging the existing bug reports! Talk is 
> cheap, etc, etc.

Ok, so the reason is that (unlike me) network-manager maintainers see no 
benefit in doing it and expect a massive support burden by doing it.

Thanks.  I think I understand now.

Sorry if that was explained already and I failed to understand it 
previously.

> > There are use-cases of network-manager without wpa-supplicant, when 
> > either wifi is not used, or when IWD is used instead.
> 
> Nothing prevents you from using iwd (while having wpasupplicant
> installed).
> 
> If you feel you must get rid of wpasupplicant (why?), then here are a
> few options:
> * use equivs to create a dummy replacement
> * recompile NM packaging with wpasupplicant dependency changed
>   (You could even contribute a patch which does this using
>   build-profiles so you can rebuild without any changes to the source
>   package!)
> * use dpkg exclude features to get wpasupplicant packages files not
>   unpacked on your system while the package gets installed.

Above are options to deviate slightly from Debian.

> * realize that wpasupplicant is small and useful to have as a fallback
>   if something ever goes wrong.

Obviously there is the option of changing my mind to no longer want what 
I wanted. :-)

> You seem to just argue over a theoretical supremacy idea, while not 
> even trying to describe which practical problem you're trying to 
> solve.

Sorry, I thought it would confuse rather than help to dive into my 
specific use-case.  I am more than happy to share that:

I want to offer system installation profiles for others than myself 
(where non-Debian deviation is not an option: I want to offer Debian not 
a fork of Debian), with a minimal core setup that includes wifi but 
excludes network-manager (due to its size), optionally adding a GUI 
(which then introduces network-manager but should do so without breaking 
the already established networking setup of a core system.

Current prototype is here: http://box.redpill.dk/

> > Again, I do understand that such use-cases are not _recommended_ but 
> > they are still _possible_ and _wanted_ for some unusual situations.
> 
> Yes, it's still possible. So go do it!
> FFS I'm using it myself right now! It is certainly possible.

My point is that unlike "a theoretical supremacy idea", possible 
use-cases are "unusual installations" as per Debian Policy 4.5 § 7.2.

Debian Policy 4.5 § 7.2 does not say that if you want to do something 
unusual then fork debian using equivs or recompiled packages, or delete 
the files getting in the way, or disable the daemons blocking your other 
daemons.

Debian Policy 4.5 § 7.2 says that if you want to do something unusual 
then overrride specific recommendations of packages you want to use in 
an unusual way.

Debian Policy 4.5 § 7.2 says that a package relationship declared a 
dependency is required to provide a significant amount of functionality.

> Better yet start improving the NM iwd backend so that it becomes 
> better.

Thanks for the encouragement.  I am not a C programmer, however.

> Maybe some day NM upstream will even reconsider and have it compiled by
> default (it comes with zero new build-time dependencies after all).
> After that they might even automatically fall back on using iwd without
> requiring manual configuration.

Improving network-manager so that IWD can be recommended is obviously 
better than discussing how to deal with not-recommended packages.

My point here is, however, that network-manager can continue to not 
recommend iwd without needing to depend on wpa-supplicant.

> > Debian Policy says to use Recommends: not Depends: for such relations.
> 
> This is your interpretation.

What is your interpretation?

Here is the relevant parts:

> Depends
>
> This declares an absolute dependency. A package will not be configured 
> unless all of the packages listed in its Depends field have been 
> correctly configured (unless there is a circular dependency as 
> described above).
>
> The Depends field should be used if the depended-on package is 
> required for the depending package to provide a significant amount of 
> functionality.

> Recommends
>
> This declares a strong, but not absolute, dependency.
>
> The Recommends field should list packages that would be found together 
> with this one in all but unusual installations.

> Please understand that the Debian project still has not managed to
> produce a way to turn mailinglist discussions into working code.
> 
> The way to reach your goal is to improve the code by debugging current
> bugs (which there are quite a bunch of in the iwd backend of NM) and
> submitting patches upstream. As already mentioned, the debian packaging
> of NM is already ahead of the game on being cutting edge w.r.t. iwd.

The way to reach my goal of using non-mainstream cutting edge wifi tool 
for unusual setup, with the least friction from Debian, is not to make 
that tool mainstream, but to convince a mainstream package to 
acknowledge that the non-mainstream tool has unusual but real (not only 
supremacy theoretical idea) use cases, and therefore relax a dependency 
to only recommend.

> The ball is really in your court! If you want to support widespread
> iwd usage, then improve the code!

Seems you are talking about changing the tool to become mainstream.

That would indeed be awesome, but is not in my court and not what this 
conversation is about.

> This is the last time I'm repeating myself on this topic....

I am sorry if I am tiring you.  I appreciate your input.

> There are no progress being made anymore on the iwd backend in NM! 
> Noone is working on improving it! Thus don't expect progress to be 
> made, unless you contribute!

Thanks for emphasizxing this important detail related to improving 
integration of iwd with network-manager.

My interest is in having network-manager co-exist more smoothly with 
iwd.

Yes, obviously one magnificent way of co-existence would be perfection, 
but there are other ways - where one way is to relax a dependency ot a 
recommendation.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-utopia-maintainers/attachments/20200712/f9b76429/attachment-0001.sig>