Discussion: Using copr for building SCLs

Miroslav Suchý msuchy at redhat.com
Wed Jun 26 11:06:00 UTC 2013


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.

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



-- 
Miroslav Suchy
Red Hat Systems Management Engineering
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scatch.png
Type: image/png
Size: 63755 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/copr-devel/attachments/20130626/4548e787/attachment-0001.png>


More information about the copr-devel mailing list