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.
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?
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
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.
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.
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.
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.
koji-devel@lists.stg.fedorahosted.org
-
Mike McLean -
Neal Gompa