On Mon, Aug 31, 2015 at 1:35 PM, Mike McLean <mikem@redhat.com> wrote:

On 08/28/2015 11:59 AM, Neal Gompa wrote:
> Hey all,
>
> I just saw the Koji 2.0 presentation online, and I'm quite interested in
> it, especially with the concept of being able to build more than RPMs.
> For example, I'd like to see Koji to be able to do reproducible builds
> of Debian packages with debbuild[1] (using RPM spec to build Debian
> packages) or even traditional methods, virtual machine bundles (qcow2
> and ova), container bundles (Nulecule, appc), and some configurability
> to support building for a multitude of distros and targets.

Thanks for watching my talk!

> Essentially, I'd like to see some of the interesting capabilities that
> the Open Build Service (building for multiple distribution targets,
> building virtual machines, container bundles) in a nice, easy to deploy
> Python 3.x-compatible application. OBS is difficult to set up, maintain,
> and integrate into existing workflows, while Koji doesn't try to be an
> all-in-one replacement for everything.
>
> Would Koji 2.0 be flexible enough to do all these things without
> becoming like the OBS?

Koji won't be able to natively support every possible type of build, but
through the content generator feature, we want to provide a mechanism
where build processes that are separate from Koji can interface with the
hub in useful way without giving up the

Giving up what? In any case, I don't think Koji should support everything out of the box, but it should be dead-simple to extend it to support more. I do expect that some of these I brought up will be in Koji, as they would be useful deliverables for Fedora, CentOS, and RHEL. For example, the virtual machine and container bundles would be quite handy to be able to generate from Koji. Atomic trees too!

> Also, on another note, why can't Koji 2.0 use the Python 3.4 Software
> Collections[2] on RHEL 6/7? RHEL 7 now has Python 3.4 in EPEL[3], too.
>
> [1]: https://apps.fedoraproject.org/packages/debbuild
> [2]: https://www.softwarecollections.org/en/scls/rhscl/rh-python34/
> [3]: https://bodhi.fedoraproject.org/updates/?packages=python34

That is a good point, but it does complicate deployment. We may well go
this way for the server side in the end, but I am hesitant to add such
dependencies for rhel clients.

I honestly don't see a good reason to not have everything have a hard requirement on Python ≥ 3.4, given the availability of the software collections. What's the point in them if you're just going to ignore them anyway for stuff like this? Making it backwards compatible to Python 2.6 is going to be challenging, especially with some of the behaviors and capabilities different between Python 2.x and Python 3.x. The Python 3.4 software collection isn't an enormous dependency, so it shouldn't be bad the Koji 2.0 client for supporting RHEL 6. Besides, a subset of folks are going to be using Koji clients with RHEL 6, and over time, other code that Koji will work with may likely be Python 3.x only anyway.

One extra step won't make people jump you over the deployment setup.

真実はいつも一つ！/ Always, there's only one truth!