On Mon, Dec 11, 2017 at 04:50:03PM -0500, Jarod Wilson wrote:
> On 2017-12-11 9:24 AM, Don Zickus wrote:
> > On Fri, Dec 08, 2017 at 05:24:22PM -0500, Jarod Wilson wrote:
> > > > It is, but was specifically added so kernels that want to do overrides like
> > > > RHEL could add their own custom configs/debug and configs/generic.
> > > >
> > > > I am open to name changes but the goal was to use Fedora configs as a base
> > > > and then allow the ability to override through other directories.
> > > >
> > > > So if you have a proposal to allow that, I am open to it. :-)
> > >
> > > Why not configs/fedora/{generic,debug} and then we tack on a
> > > configs/rhel/{generic,debug} when forking for the next RHEL kernel? Trying
> > > to keep them from polluting each other with specific names?
> >
> > Ok. I don't have any objection to that.
>
> Something I haven't actually looked at... Are those 'generic' and 'debug'
> items actually files, or folder full of individual config option files, like
> we have in Red Hat Enterprise Linux 7's tree? Either way, we could still do
> individual files under configs/rhel/generic/CONFIG_FOO that override either
> a stack of files or an individual file from Fedora.
That was the plan. Fedora provides individual files and we have the ability
to override it with our changes. In fact, I am hoping to go one further and
provide our changes as feedback to Fedora as suggestions for them to
consider. But that is a side benefit.
>
> I'm quite partial to the one config option per file route we've taken in
> RHEL7, because people so infrequently get it wrong, where the old pile of
> files approach in RHEL-6, people were frequently adding config options to
> what were originally the Fedora configs, iirc, rather than the RHEL override
> configs. The one config per file approach is also less prone to requiring
> rediffing when someone else's config option gets in before yours. I think
> having configs/fedora/* for the base and configs/rhel/* for the RHEL
> overrides/updates/additions should be clear enough that it won't get tanked
> either, and continues to provide the benefit of collision avoidance.
Yup. Makes sense.
I will put together a patch to share either tomorrow or the next day.
Cheers,
Don
_______________________________________________
kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
