Playground Repo Requirements Document

Tadej Jane┼ż tadej.janez at
Tue Mar 4 13:01:31 UTC 2014

On Mon, 2014-03-03 at 12:16 +0100, Honza Horak wrote: 
> 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.

I agree with that.
I also agree with what Alek Paunov wrote, that this could be extended to
providing old/compat packages of some software.

> 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".

Well, this is certainly a creative idea, but I currently have mixed
feelings about it. What's the gain in creating a RPM package with
the .repo file and somehow telling the user what will happen (e.g. "Be
warned, some Fedora packages from the main repo will get updated"),
compared to just pointing users at a COPR repo with the appropriate
description on its web site?


More information about the env-and-stacks mailing list