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 -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]

Reply via email to