Playground Repo Requirements Document

[Honza Horak]

On 03/01/2014 07:10 PM, Tadej Janež wrote:
> On Thu, 2014-02-27 at 13:53 +0100, Marcela Mašláňová wrote:
>>>
>> You are right we reached some conclusion on conflicts and replace, but
>> what if we want for example new v8? We have terribly old v8 in current
>> Fedora and conflicts might be a good solution in this case.
>
> I think the Playground repo is not the right place to start providing
> newer versions of existing packages in Fedora's main repository.
> My arguments are:
> 1) The package in the main repo went through a proper package review.
> The replacing package didn't.
> 2) The package's maintainer probably has reasons why he hasn't updated
> the package (we should trust maintainers by default and not over-ride
> them).
>
> The way to approach this, in my opinion, is to talk to the maintainer of
> the package in the main repository and work out if it is reasonable to
> update the package in the desired Fedora version or not.
> If the reason why the maintainer hasn't updated the package is lack of
> time, applying for co-maintenance is the way to go.
>
> There will be cases when the maintainer doesn't want to update the
> package in the main repository and a newer version is needed/desired.
> In case the package is:
> 1) some leaf package (e.g. an application), it would be sensible to just
> create a COPR repo for it.
> 2) part of a software stack (e.g. a library), it would be sensible to
> create a SCL with the required versions of the packages of the software
> stack and provide it in the Playgroud repo. This SCL could then be
> required by the applications needing this particular versions.

Right, that makes sense for me; allowing conflicts and updates seems 
like allow creating too big mess.

I can also see another cases:

3) introducing a new package under a different name --say we want to 
prepare a new un-stable/dirty version of a package foo, which is already 
in Fedora and we'd like to introduce it in Playground (which would mean 
the package foo would be updated for every user who has enabled 
Playground). If we introduce the new package under featurex-foo or 
userx-foo, we can safely add it into Playground.

4) We have a stack of packages that I want to deliver to Fedora users, 
but the stack would update some packages from Fedora base repo and/or we 
do not want to use SCLs. Then we can get a Copr repository as a RPM 
package and include this RPM in the Playground, so people installing 
this RPM package would actually say: "Yes, I want to enable these 
packages and I agree to get some of my Fedora-base packages updated".

Honza