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
> 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.