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