1 Big repo vs multiple small ones

Richard Hughes hughsient at gmail.com
Thu Mar 27 08:34:17 UTC 2014

On 26 March 2014 18:20, Marcela Mašláňová <mmaslano at redhat.com> wrote:
> I realize we should CC'ed hughsie long time ago. Hughsie, do you have any
> plans how to easily pick repositories by PK?

Well, I'm looking at this from a high level point of view. Now we have
a depsolver doing SAT we can mix repos and have a lot more packages
without the depsolve taking order-of-magnitude more time to complete,
so technically wither is possible. The question is if we want to do
that. Having lots of small repos means that you can build a layering
up of products nicely, but what happens when the end user (or admin)
disables a repo that provides packages that other repos depend on?
Best case we stop getting updates and the packages get stuck at their
present versions forever, worst case we get hacked because libssl
can's be updated as it deps on a package which deps on a package that
can't be solv'd.

In GNOME Software when the client "removes" a software source, all the
packages previously installed from that source are removed. This
prevents the problem above, but means we can only show "leaf" repos,
rather than core ones like fedora or fedora-updates.

So, there's no clear-cut winner either way. I don't think it matters
if you have numerous small repos or one big one, but I think the
small-repos idea has to have some kind of dependency chain so you
can't disable "base" and then try to install stuff from "desktop".


More information about the env-and-stacks mailing list