1 Big repo vs multiple small ones
tadej.janez at tadej.hicsalta.si
Wed Mar 19 23:24:38 UTC 2014
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 "big"
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
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 admit this will be hard to achieve but I think this is the area where
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.
More information about the env-and-stacks