On 08/24/2011 04:29 PM, Chris Lumens wrote:
Why do you only want to do this in Fedora?
So that we can notice/recall later when forking next rhel that default for rhel 6 is different. Another question is whether to change the default this way for rhel as well, I'd be careful here. I have no strong opinion about what the default in rhel should be but I'm inclined to current behaviour. Now the default for rhel 6 is ONBOOT=yes only for devices activated during install. It differs from rhel 5. Why? In rhel 5 we used to have network config screen with a device preconfigured to be activated after reboot, so the user kind of acknowledged/confirmed it by going "Next". Now with nm-c-e the device that would be autoactivated after boot by default is not presented this way [1]. Also, checking "Connect Automatically" in nm-c-e has a side-effect of activating the device (unlike the corresponding choice in rhel5 network configuration screen) I don't suppose the these different code paths for rhel/fedora will be preserved in next rhel with UI redesign as the network activation/configuration code will change a lot I think, so it is just to fix the rather wanted bz for couple of Fedora releases before new UI comes and to record in the code that rhel behaves differently. [1] I proposed a patch that would present this choice together with some other options some time ago but it was not acked. It may be also something to consider for anaconda part of network configuration UI.
diff --git a/pyanaconda/installclass.py b/pyanaconda/installclass.py index 4c599d1..576481f 100644 --- a/pyanaconda/installclass.py +++ b/pyanaconda/installclass.py @@ -211,6 +211,9 @@ class BaseInstallClass(object): return self.productMatches(oldprod) and self.versionMatches(oldver) and archesEq(arch, productArch) + def setNetworkOnbootDefault(self, network): + """Default for autoactivation of network devices after reboot""" + def __init__(self): passThis is okay as far as Python goes, but it looks weird to me. Can you toss a "pass" into setNetworkOnbootDefault?
I've no problem using pass instead of the (not very enlightening) docstring. It's just a practice (we don't use) to use docstring instead of pass. Although it is not consistent with what we are doing in installclass.py, I did it because I made this version after Brian's review and I recalled (I could have been wrong) that he had been talking about it on anaconda-devel-list or IRC so I wanted to curry favour by that. Radek _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
