----- Original Message -----
On Wed, 13 Mar 2013 05:29:56 -0400 (EDT)
Bohuslav Kabrda <bkabrda(a)redhat.com> wrote:
> ----- 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
> >
>
okay - looking at that mock config you don't even need to do that.
1. you add a repo to the copr itself to use for buildreqs
2. in that repo you setup a groups/comps file for yum - which says
<group>
<id>buildsys-build</id>
<name>buildsysbuild for scl ruby193</name>
<description/>
<packagelist>
<packagereq type="mandatory">scl-utils-build</packagereq>
<packagereq type="mandatory">ruby193-build</packagereq>
</packagelist>
</group>
then yum will add this buildsys-build to the original buildsys-build
and install ALL of the pkgs in the group by that name in ALL repos.
see - just by adding a repo you can change the buildtools.
Nice :)
Question: What would happen if I wanted to start building the SCL from the scratch in copr
and therefore ruby193-build package would not exist yet? Would the buildroot
initialization fail or just ignore the missing package?
Idea:
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).
Thanks,
Slavek.
-sv
--
Regards,
Bohuslav "Slavek" Kabrda.