On 20.07.2011 21:59, John Dennis wrote: > On 07/20/2011 01:30 PM, Alexander Bokovoy wrote: >> Actual<platform> value is substituted using top-level Makefile's >> SUPPORTED_PLAFTORM= variable (defaults to 'redhat', can be redefined >> without modifying Makefile, in package building scripts, for example) >> and then ipapython/services.py is generated from ipapython/services.py.in > > Why can't the platform be resolved at runtime instead of part of a > static build? That would be more flexible wouldn't it? We would ship the > same code in each release which is a win for robustness and > reproducibility. I guess I don't see the advantage of static build time > code selection in a language like Python. The reason for it is that runtime platform selection simply gives no advantages in IPA case. A typical deployment is a distribution of a prepared package to multiple clients, not building freeipa code on every single client with a purpose to run ipa-client-install on it. At this point we already know the platform. Replacing this knowledge with run-time detection that can go wrong and would require more extensive knowledge and effort to verify that platform is detected reliably isn't really productive.
> Earlier you said: > >> I'll try to avoid using package management tools > > but since you're relying on build tools you're implicitly relying on > package management tools. I was talking about using package management tools in runtime where one would incur computational costs. In proposed solution I'm trying to delegate a decision point to a package maintainer or a developer which already knows a platform s/he works with. There is no runtime overhead at all and single make SUPPORTED_PLATFORM=foobar would be equivalent to already utilised make -- / Alexander Bokovoy _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
