Few updates about Playground repo

[Honza Horak]

On 04/20/2015 05:10 PM, Miroslav Suchy wrote:
> On 04/20/2015 04:14 PM, Honza Horak wrote:
>>>    * 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?
>
> The information is possible to get from RPM:
> rpm -qi spark-cli:
> ...
> Vendor      : Fedora Project COPR (msuchy/spark-cli)
> ...
> However we do not have tools to handle such information.

Thanks, can be handy... once.. :)

>>>    * 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?
>
> TMTOWTDI
> e.g. disable the repo and then
> chattr +i /etc/yum.repos.d/_playground_${copr_name}.repo

Whatever way we do it, it wouldn't be that transparent for users as if 
we do it the usual way -- which is `user enables repository once and the 
content changes on the server`.

>>>    * 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.
>
> You will have to store it somewhere. OK. *If* it will be on the same
> machine, we can hardlink it.

Or just symlinks?

     pushd /path/to/playground_repo
     rm -rf *
     for copruser coprname in `get_playground_coprs`; do
         mkdir -p $copruser
         ln -s /path/to/results/$copruser/$coprname $copruser/$coprname
     done
     createrepo .
     popd

This would do the trick on the server (basically).

> You will have to run reposync (and from my experience from
> softwarecollection.org) it has more then one weak points.

Yeah, I'm sure it will be more complicated than the snippet above, but 
if we even speak about few hours once, it shouldn't be blocker.

> So initial setup, some task four times per year... But still the other
> option have zero maintenance and zero setup time.

What is more important for me than zero setup time is that, it makes it 
more difficult on users' side -- setting up cron job, handling 
permissions, situations user wants to disable some repo..

This is how I as a user would like to see it working:

I want to check what is in there:

     dnf playground search 'sparc'

Now, I can either enable/disable one or more coprs from playground repo:

     dnf copr enable 'msuchy/spark-cli'
     dnf copr disable 'msuchy/spark-cli'

(since all playground coprs are still coprs, I'm able to do so)

Or decide to enable all of them:

     dnf playground enable

Anyway, Mirku, would you mind to show up on Thu to talk about it on Env 
& Stacks meeting? I remember the last time we talked about it you 
weren't there, which did proofed to not be ideal, since now we need to 
reconsider it again. Let's look at it the last time and decide finally 
what to do.

Honza