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 <ngompa13(a)gmail.com> wrote:
On Wed, Sep 6, 2017 at 4:04 PM, Clark Williams
> 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
> setups provide a separate package. I guess the mock-configs.src.rpm could
> generate sub-packages: mock-core-configs (e.g. Fedora), and possibly
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 -- buildsys(a)lists.fedoraproject.org
To unsubscribe send an email to buildsys-leave(a)lists.fedoraproject.org
The United States Coast Guard:
Ruining natural selection since 1790