On Thu, Jun 21, 2012 at 2:52 PM, Henrik Hallberg <henrik@k2h.se> wrote:
Setting NETWORKS to 'last' or '@last' restarts the profiles that were running at the previous 'netcfg-daemon stop'.
I think I'd rather have two extra options for netcfg, namely 'save' and 'restore' and add a '[@]restore' target to netcfg-daemon, but besides that I have my doubts about this whole idea. Can anyone describe a good use case? When is it not okay to list all profiles you might need in NETWORKS=()? Further, suppose 1) You manually connect to a network not in your NETWORKS(). 2) You connect to it on a day-to-day basis because at every boot, netcfg-daemon connects to it. 3) One day, connecting fails and the network is lost from the saved state 4) You have to connect to the network again, manually I don't really like this style. Currently netcfg-daemon manages the networks it manages and can even co-exist with manual netcfg connections (as long as they don't share an interface there is really nothing to worry about). The only exception is the menu target, which makes it possible to connect to not explicitly specified targets, but since this behavior is entirely stateless I'm OK with it. What I think is the underlying request is support for locations. Of course netcfg profiles already provide support for locations on a per-interface basis, but apparently there is a need to group profiles into locations. If that is what this is all about, I am not in favor of a last-connected feature. Much rather I'd have support for meta-profiles/profile-groups in some way. Regards, - Jouke