On Tue, Sep 17, 2013 at 8:33 AM, Marcela Mašláňová <mmaslano(a)redhat.com>wrote:
On 09/16/2013 08:25 PM, Toshio Kuratomi wrote:
> == Build & Distribution ==
> * What are the impacts on the build system?
Until now we used internal instance of koji. I can sum up what we did
> * How are we preventing build problems from the mainline package
> from interfering with the scl package and vice versa?
There are no build interference problems. Package has specific name.
> * How are we allowing for a package to be built in more than one scl?
Didn't solve yet. We related build targets (collection) with branch. How
to build for more collections is a good question for our releng. But do we
> * How are we allowing for differences between scls? (ie:
> ruby1.9.3 scl with rubygem-foo1.0; ruby2.0 scl with rubygem-foo2.0)
> * How are we preventing build problems from one scl from
> interfering with a different scl?
> * Remi mentions that he thinks it would be done in a separate
> branch. Would we need a branch per scl that the package is built in?
Can't happen. Every branch is set to build in some tag. Packages tagged in
one tag are shipped as one collection. You are able to inherit from one tag
As I said I prefer branch per collection. How else would be tags defined?
> * How do SCLs get distributed?
> * Is this a "separate repo" or is it just in the normal repo(s)?
Currently separate repo.
> * (toshio) Both. Some SCLs can go into Fedora Commons which
> would continue to have one repo. SCLs in the outer rings would have
> some separate structure.
> * Build section would benefit from minor sections, perhaps:
> "Overview," "Testing" and "Example"? Sections need a
bit more color to
> be understandable.
> I'll add it.
I would like to request that one more question/issue be addressed in this
Red Hat has made a GREAT tool available in the devtoolset (
but currently there's no way to take advantage of it in the EPEL. Can a
plan to enable the use of the devtoolset for Koji builds for the EPEL for
EL 5/6 be discussed as well?
The hope is that then packages that make use of the devtoolset could be
created and then people who have subscriptions to the devtoolset could make
use of them.
For example, I am working on packaging odb (
), but it requires gcc
4.5 or greater for plugin support and that is only available on EL 5/6
through the devtoolset. So if it was possible to build on Koji using the
devtoolset, then it would enable odb to be packaged for EL 5/6 and then
those with access to the devtoolset could make use of it.