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