Playground DNF plugin

Tadej Jane┼ż tadej.janez at
Wed Apr 16 10:34:02 UTC 2014


On Tue, 2014-04-15 at 15:05 +0200, Miroslav Suchy wrote: 
> I created first prototype of Playground repo (you know - release early...).

Cool, nice to see some code!

> There is an API call to get list of those projects:
> (currently undocumented, because I plan to make some changes).

At the time of writing, it gives me "500 Internal Server Error"?

> Is this the path we want to follow? Questions? Comments?

As I tried to explain on yesterday's Env and Stacks WG meeting [1], the
previous steps on defining the Playground repository lead in the
direction of having a real repository (for example, the first paragraph
of [2] talks about "Repositories/packages successfully built and
satisfying the Playground repository's Policies are copied into the
Playgroud repository.").

I think the approach you presented (having a set of COPRs with the
Playground flag + the Playground DNF plugin that handles them) looks
interesting, but I would like to hear how you envision extending this
approach to support some of following features:

1) Signing packages with an independent Playground repository key. I
assume that if we add support for signing packages in Copr, each <user>
or each <user-repo> will have its own key and when the <user-repo>
becomes part of the Playground repository, we'll want to sign it with
the Playground repository key.

2) Automatic gating/sanity-check on package update. Let's say user joe
requested his foo repo be added to the Playground repository. To process
the request, packages in joe/foo are sanity-checked with Taskotron and
added to the list of Playground repositories. The next day Joe updates
packages in joe/foo and (inadvertently) breaks them so they no longer
pass the sanity-checks of Taskotron. In the case of having a real
repository, where packages are feed from COPRs (i.e. copied over), users
will continue to see the old packages in joe/foo that passed the sanity
checks, whereas in case of this "virtual" repository, they would
automatically be upgraded and break their systems.

Note about disk space constraints: Couldn't we hardlink the copied
packages so they wouldn't consume twice the amount of space?

3) Handling package/repository removals (leaving legal issues to the
other thread [3]). For example, user joe removes his joe/foo COPR that
was also part of the Playground repository. After a week, frank
encounters a problem with a package from the joe/foo COPR that he
previously installed on his system. His tech-savvy fried bob is trying
to reproduce the problem on his system but he is unable to since joe/foo
is no longer available.



More information about the copr-devel mailing list