I think the main reason Miroslav wants to do this is so that we can decouple distro version changes from code changes and be able to make configs available quickly after branching, without being forced into a checkin/testing cycle for code that might not be ready for prime time. So, I like it for that reason; if it makes life easier on other people that maintain custom configs, so much the better.
On Wed, Sep 6, 2017 at 3:17 PM Neal Gompa <[email protected]> wrote: > On Wed, Sep 6, 2017 at 4:04 PM, Clark Williams <[email protected]> > wrote: > > So what variant configs are out there? If there's a ton, then I agree we > > should focus on the core configurations and let people that have their > own > > setups provide a separate package. I guess the mock-configs.src.rpm could > > generate sub-packages: mock-core-configs (e.g. Fedora), and possibly > > mock-configs-centos? > > > > > > The variants today are extended from the core configs shipped by mock. > For example, the Mageia package is an extension of the core configs > shipped in the core package. Likewise for RPM Fusion. Other developers > extend existing ones or implement the empty "custom configs" for their > own purposes. That's why I suggested mock-core-configs, which would > include the base Fedora, Mageia, and EPEL configurations that we ship > today in mock itself. > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > _______________________________________________ > buildsys mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- The United States Coast Guard: Ruining natural selection since 1790
_______________________________________________ buildsys mailing list -- [email protected] To unsubscribe send an email to [email protected]
