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