On Sat, Aug 22, 2020 at 06:56:29AM -0400, Prarit Bhargava wrote: > > and final files are not tagged with 'rhel'. > > That's the current way dist-configs does things. I debated adding a rename > function to the os specific configs targets but think that should be a separate > patch. *This* patch is to fix them so that they actually work ;) > > > > > It would be nice to have a target that generates both flavors at once. > > With that I can easily check how the config is on both and if the > > changes are getting applied correctly. But yes, I can easily script > > that around rh-configs/fedora-configs as well, > > > and thus why I'm not > > seeing a reason for the dist-configs target, at least not as it is > > now. Perhaps we should hide it (from the help), as an internal target > > that should only be used to build the two other ones. Thoughts? > > Not a bad idea. dzickus? jforbes? I can certainly respin and remove the > 'dist-configs' entry in 'make rh-help'. Just trying to understand the proposal. Have 2 targets exposed with dist-help: rh-configs and fedora-configs? dist-configs would be supported but not as an expected common command and would only be seen through dist-full-help? And the main reason is really time, right? If generating un-used fedora configs only consumed less than a second of time, we wouldn't care. It is because it takes about 10 seconds it is a problem? Which is fine, I just want to understand the true underlying problem. Cheers, Don _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
