createrepo run after mock

[Dennis Gregorovic]

On Thu, 2010-02-11 at 10:12 +0200, Mike Bonnet wrote: 
> On 02/10/2010 11:27 PM, Dennis Gregorovic wrote:
> > On Wed, 2010-02-10 at 16:09 -0500, Seth Vidal wrote: 
> >>
> >> On Wed, 10 Feb 2010, Mike McLean wrote:
> >>
> >>> On 02/10/2010 03:41 PM, Roland McGrath wrote:
> >>>> I'd certainly like it to be de rigeur for all the canonical forms of
> >>>> producing a passel of rpms.  A directory full of fresh built rpms that is
> >>>> not directly usable as a repo is just silly!
> >>>
> >>> Not every set of rpms makes sense as a repo.
> >>>
> >>> If you really feel this way, perhaps you should request that yum support
> >>> a dir of rpms as a repo. ;)
> >>
> >> repoquery --repofrompath and the yum tmprepo plugin.
> >>
> >> -sv
> > 
> > I agree with Seth that there would be significant utility in having
> > repodata readily available for brew builds.  I suggest that for regular
> > builds the repodata live at /data/repodata within the package dir.  For
> > scratch builds, the repodata directory could live right inside the
> > task_123456 dir.
> > 
> > I think Mike is right that if we do add repodata creation, having it on
> > the hub would make the most sense.
> 
> We have a Koji hub plugin system now, which makes implementing this kind
> of post-build operation pretty simple.  I think the last time we talked
> about something like this, we were concerned about the load on the hub
> from constantly running createrepos.  However, I guess running a
> createrepo on a handful of packages won't cause a huge increase in load,
> and if it's really useful it's worth it.

Using a plugin would be handy if we want to store the repodata separate
from the packages.  Otherwise, we would need to add a mechanism to
upload the repodata back to the hub (assuming that the box running
createrepo doesn't have rw access to /mnt/koji).  However, adding some
generic routines for uploading content to the /data and /scratch
directories could be useful down the line.  

-- Dennis