Discussion: Moving WPA_SUPPLICANT out of base and into dports
justin at shiningsilence.com
Mon Oct 13 18:28:54 PDT 2014
This is ranging away from the original topic a bit, but: if we wanted to
really say "Let's use packages to offset work on the kernel/world", what
else could we pull out? It's a bit dangerous with wpa_supplicant since you
can end up in a chicken-and-egg scenario where it couldn't be installed
without network, but it was needed for network. However, there's plenty
other areas where this could apply but be less dangerous. I really like
the idea of offloading the unessential work to someplace where upgrades are
already happening, like ports.
We're wandering out of BSD land ("The base system is complete") and into
Linuxville ("packages are necessary to do anything ever"), but that's OK
right now as a thought experiment. Are there other software bits we'd want
to package, or packages we'd want to add to the default release install?
On Sun, Oct 12, 2014 at 5:47 AM, John Marino <dragonflybsd at marino.st> wrote:
> The HOSTAPD and WPA_SUPPLICANT vendor branches weren't updated for over
> 4 years until Alex Perrin helped us bump to version 2.1. Since then
> versions 2.2 and 2.3 have been released.
> I've spent a few hours already trying to update it again, but it's quite
> complex. The code changes rapidly and the DragonFly makefiles,
> inherited from FreeBSD, support a bunch of custom build options with
> variables set in the Make.conf file.
> I suspect nobody knew about these variables and thus don't use them, so
> removing support for them would definitely make future maintenance
> either. So it would be interesting to hear if anyone customizes
> WPA_SUPPLICANT through make.conf.
> While pondering this, I began asking myself why WPA_SUPPLICANT and
> HOSTAPD were in base at all. We could easily move this to dports and
> add the packages as mandatory for nrelease. That would have the
> following benefits:
> * Easier to maintain
> * More likely to have current version available
> * Custom options would be available via normal ports dialog
> * Base would contract
> We could probably ease WPA_SUPPLICANT and HOSTAPD out gently. For
> example, version 2.1 wouldn't build by default but it would still be in
> base so Make.conf switch could activate it. After a release or two when
> it's clear having in dports works well, we can remove it from base
> What do people think? Is there some crucial reason why WPA_SUPPLICANT
> and HOSTAPD have to remain in base? Feedback on this topic would be great!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users