On 8/24/20 10:31 AM, Justin Forbes wrote: > 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. > So the short answer here is "no, we don't want to do that" :) P. > 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
