Playground Repo Requirements Document

Honza Horak hhorak at redhat.com
Tue Mar 4 14:02:11 UTC 2014


On 03/04/2014 02:01 PM, Tadej Janež wrote:
> 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?

Right, I don't remember which use case I had on my mind with the 4th 
point, so let's just stay with the 1, 2 and 3 ;)

Honza


More information about the env-and-stacks mailing list