On 03/20/2014 12:24 AM, Tadej Janež wrote:
On Tue, 2014-03-18 at 16:22 +0100, Marcela Mašláňová wrote:
> Today was discussed whether we want one big repo or multiple small ones
I hope we all agree that the general idea behind the Playground repo is
to have some middle ground between current Fedora's main repo and COPRs.
However, as the saying goes, the devil is in the details, i.e. we need
to find out what this middle ground is.
My vision for the Playground repo is to provide a single
repository with a little more integration work being done at the repo
level than to just provide a curated collection of multiple COPRs.
In my view, two of the main things driving the creation of the
Playground repo are:
1) Some things take a very long time to get into Fedora because of the
current (suboptimal) review process.
2) Some things simply cannot go into Fedora because of the current
We can solve those two things and at the same time retain one big
integration point offered by the packages in the Fedora's main
"Users should always be able to install the latest packages from
Fedora's repos regardless of what other Fedora packages are
I wouldn't fight for integration here. If you want to do integration
here, then the process is not much different from inclusion of packages
For the Playground repository I would modify that to:
"Users should always be able to install the latest packages from the
Playground repository regardless of what other packages from the
Playground repository and the Fedora's main repository are installed."
I disagree. Not all latest versions of packages must go through
Playground repo. In some cases it might be more work than needed. I
would leave it up to maintainers with dozens of packages, what they think.
I admit this will be hard to achieve but I think this is the area
we have to do the integration work so that the users of the Playground
repository don't have to do it themselves.
For example, Fedora really won't make a good impression on a user that
has to decipher an error message about unresolved conflicts in the
transaction set when he tries to install *some cool new package*.
How to achieve this?
We'll need to develop tooling that will automatically detect when there
are conflicting files between multiple packages or just conflicting
package names and suggest to the packager what are the possible
solutions to resolve it.
And in cases when a package carries an explicit Conflicts: tag, we might
just flag it for manual review.
I still don't buy the idea - no conflicts in repo.
env-and-stacks mailing list