Discussion: Using copr for building SCLs

Bohuslav Kabrda bkabrda at redhat.com
Wed Jun 26 11:15:06 UTC 2013

----- Original Message -----
> On 06/25/2013 12:39 PM, Bohuslav Kabrda wrote:
> > While both of the ways seem to have their pros and cons, I tend to agree
> > with Mirek.
> > Before deciding which way to go, there are some questions that will need to
> > be answered for this approach:
> > - How do we map the chroots to the backend repo? What I mean by this is,
> > that if you build two SCLs in one copr, you will need two chroots, say
> > ruby193-fedora-19-x86_64 and python26-fedora-19-x86_64 (will we enforce
> > this naming scheme?). This makes me think that we should place all the
> > builds done in these chroots to fedora-19-x86_64, not in their separate
> > directories (so that we can generate repofile that points just to this dir
> > - I'm not sure whether yum would be able to cope with arbitrary named
> > directories in a copr and installing dependencies from them). CCing
> > @tradej on this, since this would probably need some altering of repofile
> > generation.
> I do not think we should grant user the rights for creating new chroot.
> I have different suggestion - see below. But when you are speaking about
> two SCL... this need to be solved on SCL side.
> Let assume that you have ruby193 and python26 collection and I want to
> have build libselinux. And I plan to use it under both collection at the
> same time. But libselinux have subpackages with ruby and python
> bindings. So I probably need to build it at one shot for both
> collections. Which is currently impossible. And it is beyond COPR. And
> even Koji.

Not really. You may just want to build multiple separate SCLs in one copr. Sharing libraries between them is issue of SCL concept itself, yes, but it has nothing to do with building more scls in copr.

> > - Will any user be able to create an alternate chroot? What if two users
> > decide to use same name for a chroot? (This leads me to a thought of
> > making the modified chroots per-user (e.g.
> > bkabrda/ruby193-fedora-19-x86_64), but I may be overengineering here).
> I suggest that users will use chroots, which we will gave them. But that
> chroots will be editable (see attachment). And when you click on chroot,
> you will be able to add additional package to chroot.
> For example for SCL you will first normally build meta package, then you
> will click on epel6-x86_64 chroot. And you will say you want to add
> ruby193-build package to your default buildroot.
> We will store it in DB in
> custom_chroot: id, copr_id, mock_chroot_id
> Backend will retrieve that info and will create mock config with:
> config_opts['root'] = 'epel-6-x86_64'
> config_opts['target_arch'] = 'x86_64'
> config_opts['legal_host_arches'] = ('x86_64',)
> config_opts['chroot_setup_cmd'] = 'install @build ruby193-build'
> config_opts['dist'] = 'el6'
> and pass this mock.config to builder.
> There is no need to give it name. Or more precise the name of such mock
> config can by ugly as custom-mock-$copr_id-$chroot_id because it will
> not be seen by user.

So this is basically like my proposal (=personalized chroots), but without actually naming the chroots, right? That has the disadvantage that if you're building multiple SCLs in one copr, you need to alter the chroot for every build in different scl.

> --
> Miroslav Suchy
> Red Hat Systems Management Engineering
> _______________________________________________
> copr-devel mailing list
> copr-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/copr-devel

Bohuslav "Slavek" Kabrda.

More information about the copr-devel mailing list