----- Original Message -----
On Fri, 1 Mar 2013 03:54:48 -0500 (EST)
Bohuslav Kabrda <bkabrda(a)redhat.com> wrote:
> Hi list,
> I'd like to start yet another discussion about some functionality
> of
> copr, here it is: One of nice use cases for copr would be building
> software collections [1]. These however require modified mock
> chroot
> (modified config_opts['root'] and config_opts['chroot_setup_cmd']).
> I'm trying to think of a way how to do this:
What modifications do they need? Also - why can't this just be
provided
as an additional 'distro' in the form of another mock .cfg file for
that distro?
Then the user would just select that in the distro/release in the
copr
and build?
I meant something like this, only there would need to be a for frontend to let backend
know about the new SCL chroots.
>
> My proposal:
> - Use chroot names like ruby193_fedora-18-x86_64.
> - Allow users to create these chroots by modifying
> config_opts['chroot_setup_cmd'] (config_opts['root'] would be
> autogenerated from the chroot name).
Why overload the chroot name for this?
> - Store the modified information in the MockChroot table and create
> these on backend using communication channel proposed in [2] (parts
> of it already implemented in frontend).
> - Allow selecting these on copr creation/modification as more
> options
> for mock chroots, by default hidden under some kind of fancy
> clickable JS dropdown.
>
I need more info about what modification SCLs require to be able to
judge this well.
See above from my original mail. I'm attaching a diff of what I did with epel-6 mock
chroot (and if you ignore my added local repo, it's pretty trivial).
thanks,
-sv
--
Regards,
Bohuslav "Slavek" Kabrda.