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:
- We would need to allow users to create their own chroots (or more precisely allow them
to do certain modifications).
- We would need to be able to send these chroots from frontend to backend.
- We would need some mechanism for sane naming, so that we can distinguish between builds
of collections for different releases and architectures. E.g. ruby193-x86_64 is not
enough, we need to also store the information about os name (epel/fedora) and os version
(epel 6, fedora 18, ...).
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).
- 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.
Thoughts?
--
Regards,
Bohuslav "Slavek" Kabrda.
[1]
https://fedorahosted.org/SoftwareCollections/
[2]
https://fedorahosted.org/copr/ticket/8