1 Big repo vs multiple small ones

[Jaroslav Reznik]

----- Original Message -----
> 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".

I'd say these "small-repos" should not be layered on top of each other,
it's just more to have a bit more fine grained control over what's in
the repo.

But there were several use cases collected over time:
1. incubation - packages that will one day reach main Fedora repository,
just needs some time to settle down, or maintainer wished to get more
testing outside of main repo just get Copr visibility could be harder.
This stuff should have some sort of higher quality packages
2. exceptions - aka Chromium. Something that's usually high quality,
used for daily use on production systems but would be so hard to 
fulfil Fedora rules to be included in main repository/incubation repo
(even it could be in incubation repository forever).
3. misc stuff with different quality/exceptations... Maybe it's really
stuff for standalone Coprs...

So far we agreed on "Playground" - something you should not recommend
any user to enable on production machine unless he knows what to do. As
a compromise to kick the idea off.

It's definitely not going to be dozens small Copr collections but
more specific use case based repository/collection of Copr repositories.
Just keep it easy and simple.

Btw. for Playground as interim solution, DNF only would be ok.

Jaroslav

> Richard
> _______________________________________________
> env-and-stacks mailing list
> env-and-stacks at lists.fedoraproject.org
> https://lists.fedoraproject.org/mailman/listinfo/env-and-stacks
>