On Mon, Aug 24, 2020 at 9:25 AM Prarit Bhargava <prarit@xxxxxxxxxx> wrote: > > On 8/24/20 9:49 AM, Don Zickus wrote: > > 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? > > Yeah, I think that's what he's getting at. dist-configs would be an internal > only target. > I don't know why it would be considered internal only. if you are planning to use the other rpm package options, you have to have to have configs for both. If you are making config changes, and break one, it will kill the build for both. Basically, the only time you need configs for only one, is when you are planning to copy it as a .config for a non packaged build. > > > > 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. > > Right. rh-configs and fedora-configs are nice in that they build ONLY those > configs. > I don't see a problem with having them broken out for specific cases, but really by default people should be in the habit of build/check for both. if you break one, you break everything. Justin _______________________________________________ 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
