Sebastian Pipping wrote: > Ciaran McCreesh wrote: >> Because an overlay model has only a single foo-1.2. Think of it like >> stacks of paper. You've got your main repository: >> >> ::gentoo foo-1.1 foo-1.2 foo-1.3 >> >> and on top of that you put your overlay: >> >> ::extras foo-1.2 foo-1.4 >> ::gentoo foo-1.1 foo-1.2 foo-1.3 >> >> and then looking down from the top, all an overlay model package >> manager sees is the foo-1.2 from the overlay. There's no >> foo-1.2::gentoo and foo-1.2::extras, there's just a single foo-1.2 >> that's made from (gentoo + extras). > > I see. So it would not work for dependencies but it should work for > masking. That alone wouldn't make me happy, though. > > >> There's a different way of looking at it that focuses more on the >> repository level view at [1]. >> >> [1]: >> http://ciaranm.wordpress.com/2009/04/16/distributed-distribution-development-and-why-git-and-or-funtoo-is-not-it/ > > Interesting read. Can you think of anything technical that would make > moving portage to this model impossible?
It shouldn't be too difficult to tweak portage so that multiple ebuilds of the same version from different repositories are visible to portage's dependency resolver. Currently, it uses a collection of 3 repositories to resolve dependencies: installed, ebuild, and binary packages. Replacing the single ebuild repository (portdbapi class) instance with multiple instances, one for each overlay, should produce the desired result. -- Thanks, Zac
