----- 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
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
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
> 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.
Red Hat Systems Management Engineering
copr-devel mailing list
Bohuslav "Slavek" Kabrda.