It was recently brought up to me that with the impending "Python3 as
Default" change coming to Fedora it would be nice if we had Python3
client-side compatibility. The main motivation is from a developer
(Fedora Workstation User) perspective, it would be nice if the didn't
need to pull in all of the python2 stack just to be a Fedora Packager.
I don't know how big of an overhaul this would be or what it would
potentially break on the back end for the ability to still run server
side bits on EL5 machines, but I wanted to at least initiate the
 - https://fedoraproject.org/wiki/Changes/Python_3_as_Default
With mock switching to dnf, we needed to conditionally adjust mock's
package_manager config on a per-tag basis. I didn't want to add yet another
specialized field in the tag_config table, so I extended the schema to
support more flexible extra options for tags.
This set of patches adds the extra options functionality and uses it to control
set mock's package_manager option.
Each tag can now be assigned arbitrary extra options. These are stored as json
in the database, so they can be of any type that json supports. The
getBuildConfig call follows inheritance when determining these.
To tell mock to use dnf in a tag, you would run a command like:
# koji edit-tag TAG -x mock.package_manager=dnf
This setting is inherited.
Signed-off-by: Dennis Gilmore <dennis(a)ausil.us>
docs/schema.sql | 1 +
1 file changed, 1 insertion(+)
diff --git a/docs/schema.sql b/docs/schema.sql
index 3582b87..aad24a9 100644
@@ -183,6 +183,7 @@ INSERT INTO channels (name) VALUES ('maven');
INSERT INTO channels (name) VALUES ('livecd');
INSERT INTO channels (name) VALUES ('appliance');
INSERT INTO channels (name) VALUES ('vm');
+INSERT INTO channels (name) VALUES ('image');
-- Here we track the build machines
-- each host has an entry in the users table also
For the Ceph project, we're very interested in building Debian
packages on Red Hat's build system, so I've been kicking around the
idea of a Koji buildDSCFromSCM task. When I mentioned this to one of
the rel-eng guys in Red Hat, they mentioned that "content generators"
might be able to handle our use-case in Ceph. This was the first time
I'd heard of such a thing.
In your Koji 2.0 planning thread you mentioned "content generators" as
well. Can you provide more details about this?