| 1 |
On Sun, Jul 27, 2014 at 5:33 PM, Ciaran McCreesh |
| 2 |
<ciaran.mccreesh@××××××××××.com> wrote: |
| 3 |
> On Sun, 27 Jul 2014 17:26:27 -0400 |
| 4 |
> Rich Freeman <rich0@g.o> wrote: |
| 5 |
>> But, in that case you can put the necessary ebuilds into your overlay |
| 6 |
>> and then portage can make everything right. |
| 7 |
> |
| 8 |
> Oh? Please explain to us a) how the overlay interaction *actually* works |
| 9 |
> with dynamic dependencies currently, |
| 10 |
|
| 11 |
No idea. I doubt it is specified behavior. Certainly we should learn |
| 12 |
whatever lessons we can from what has been done already, but we aren't |
| 13 |
constrained by it. |
| 14 |
|
| 15 |
> and b) how it can work both in the |
| 16 |
> case you describe, and in the case where an overlay has a substantially |
| 17 |
> different ebuild for the same package. |
| 18 |
|
| 19 |
I'd think that a change in repository should probably be treated like |
| 20 |
a revbump. There is no way to know that foo-1-r1 in one overlay is |
| 21 |
the same as foo-1-r1 in another. The package manager has to figure |
| 22 |
out which overlay to use already, and if the same PV shows up in a |
| 23 |
higher-priority overlay then it is treated as a revbump of whatever is |
| 24 |
in the lower-priority overlay and it triggers a rebuild. Maybe you |
| 25 |
could get clever about checking for identical ebuilds/eclasses/etc and |
| 26 |
avoid a rebuild if it literally is the same file, but I wouldn't go |
| 27 |
further than that. |
| 28 |
|
| 29 |
Rich |
Archives