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