Few updates about Playground repo

Honza Horak hhorak at redhat.com
Mon Apr 20 14:14:43 UTC 2015

On 04/16/2015 03:38 PM, Miroslav Suchý wrote:
> On 04/16/2015 01:59 PM, Honza Horak wrote:
>> Personally, I'd prefer the first way -- create one repository on copr server side, so clients just install one repo file
>> once and just repodata will be updated. That prevents possible issues with copr repo file updating, we don't have to
>> check if user disabled the repo to not enable it by mistake etc.
> I am not sure what are you meaning first and second. However...
> There is already functionality in dnf-plugins-core, which allows you to write:
> # dnf playground enable
> Which query Copr which projects are in Playground set and store the repo files in:
>    /etc/yum.repos.d/_playground_${copr_name}.repo
> The set is currently empty :) The idea is that there would be cronjob (which user can disable), which would periodicaly do:
>    dnf playground disable
>    dnf playground enable
> which would update that set of repositories.
> The advantages of this approach - compared to one big repo - are:
>   * User have better control from where the package is coming - e.g. it comes from msuchy/foo project which is part of
> Fedora playground (compare to "it comes from Fedora Playground").

This information is not possible to get from RPM metadata, right?

>   * User can enable playground and then disable some projects (not possible with one big repository).

How is this done? Say I disable one copr in 
/etc/yum.repos.d/_playground_${copr_name}.repo by setting enabled=0 -- 
how the cron job finds out it shouldn't touch this specific repo? Since 
just by running:
      dnf playground disable
      dnf playground enable
the disabled repo would be enabled again, wouldn't it?

>   * No additional maintenance - that big one repository will need some maintainer.

It seems to me there won't be much difference in maintaining with one 
big repo (except initial implementation), it's more matter of where the 
cron job is running.

More information about the env-and-stacks mailing list