Discussion: Using copr for building SCLs
bkabrda at redhat.com
Tue Jun 25 10:39:27 UTC 2013
----- Original Message -----
> On 03/21/2013 12:27 PM, Bohuslav Kabrda wrote:
> > What if we just add "additional buildroot packages" attribute to every
> > build, similarly as we do with repos/mock chroots? Would the backend be
> > able to generate comps file on the fly for every build? This way, we
> > wouldn't even need additional chroots, we would just use the standard ones
> > and backend would only change the buildsys group on demand with certain
> > builds (heck, this way we could even build SCL-macroed packages as non-SCL
> > in the same buildroot; or build multiple SCLs in the buildroot).
> I could not imagine building one hundreds of packages this way. That
> would be PITA.
> IMO SCL setting should be related to (chroot, copr).
> Miroslav Suchy
> Red Hat Systems Management Engineering
> copr-devel mailing list
> copr-devel at lists.fedorahosted.org
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.
- As already asked above - do we enforce a specific naming scheme?
- 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).
Does this make sense?
Bohuslav "Slavek" Kabrda.
More information about the copr-devel