Playground Repo Requirements Document
alex at declera.com
Tue Mar 4 02:14:07 UTC 2014
On 03.03.2014 13:16, Honza Horak wrote:
> 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".
I think all 3 paragraphs above are very wise. Few more humble opinions:
3) could be extended with different (not only newer). If the packager is
able to get the older version coherently regarding Fedora+Playground -
4) will be really nice, but I think that for the playground .repo RPMs
should exist some form of review (e.g. from Fedora packager or by
I think that Playground could also play a nice role as a training camp
for some potential Fedora packagers and if so, which elements from the
standard process would be good to be presented in lightest possible
variant? Random thoughts:
- github.com/fedora-playground organizational account managed by
env-and-stacks and used as dist-git
- ~/index/wiki analog of the guidelines, containing also some important
excerpts of the real guidelines as friendly recommendations for possible
- ~/index/issues analog of the review request BZ, but with very easy
ticket creation e.g. filled by web interface at playground.fp.o
requiring just source COPR with successful builds for the requested
arch/branch matrix. Then our machinery should check the package for the
basic requirements: licenses, no f updates, build requires in f+p,
coherency against f+p.
- ~/package/issues as package bugtracker synced by the github api when
abrt or an user fills a bug against the package into the central Bugzilla.
P.S. Weather someone already works on JS interface (local web app) for
generating/supporting .specs files based on local yumdb and the .spec
grammar?. Is this a good idea? Showing rpmbuild and copr-cli command
lines to the future packager?
More information about the env-and-stacks