| 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 |
Archives