Playground DNF plugin

[Miroslav Suchy]

On 04/16/2014 12:34 PM, Tadej Janež wrote:
> 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.

Why you need separate 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.

I did not thought about none above. Mostly because I am thinking about
it as Playground with very low limits (and very low responsibility and
accountability). And when I play on playground I expect that some of my
sand cakes are sometimes destroyed/broken. And event Playground draft
state that
  "Users of the repository should be willing to endure a certain amount
of instability when using packages from here."

What you wrote here sounds too much complicated to me. Like next
instance of fedora-updates. And if you count in the Taskotron, then it
is even strict then current fedora-updates (in a term of process not
packaging).

I thought that Playground will be something like the-best-of-Copr plus
projects heading toward inclusion in Fedora.
Just start with simple stuff and see what works, what cause most pain,
and what is best and then evolve.
Rather then creating complicated beast and later find that it was wrong
direction.

Mirek