On Thu, 2019-05-09 at 16:42 +0100, Daniel P. Berrangé wrote: > On Thu, May 09, 2019 at 04:25:03PM +0200, Andrea Bolognani wrote: > > Unrelated to this patch, but does our default of 'native' for > > cross-policy really make sense? Unless I'm mistaken, that's the > > value we need for tools rather than libraries, and in general > > projects depend on way more libraries than they do on tools, so > > perhaps it would make sense to make 'foreign' the default and > > use 'native' explicitly for tools only. > > 'native' by default was done as it is the safe option. ie if you > don't mark a package for foreign install, the container image will > still build fine. If it was the reverse, then we'd get either > errors from apt failing to resolve deps, or worse yet, it can > even uninstall the native tool & add the foreign build which > then won't work at runtime. Have we actually tried that? Because the latter (replacing the native foreign one) would indeed be a problem, but the former (failure to resolve dependencies) would result in an error during container build and as such would be arguably a nice safety net in case we got the configuration wrong. Actually, in both cases outlined above we'll eventually get a failure, either at container build time or CI build time, whereas with the current default getting the value wrong might result in an optional dependency being silently ignored. So either way using 'foreign' as the default would possibly be an improvement. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
