On Mon, Aug 31, 2015 at 1:35 PM, Mike McLean <mikem(a)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!