| 1 |
Dnia 2014-07-22, o godz. 09:25:45 |
| 2 |
""Paweł Hajdan, Jr."" <phajdan.jr@g.o> napisał(a): |
| 3 |
|
| 4 |
> On 7/21/14, 11:52 PM, Alexander Berntsen wrote: |
| 5 |
> > Michał has documented the shortcomings of dynamic deps in our wiki[0]. |
| 6 |
> > (Thank you!) This documentation also includes two of our possible |
| 7 |
> > solutions. |
| 8 |
> > |
| 9 |
> > [0] <https://wiki.gentoo.org/wiki/Project:Portage/Dynamic_dependencies> |
| 10 |
> |
| 11 |
> Thank you, this is very useful. I didn't understand the issue much |
| 12 |
> before reading that page. |
| 13 |
> |
| 14 |
> One question: why for "Removal of a USE flag along with the relevant |
| 15 |
> dependencies" dynamic deps say "revbump + unnecessary rebuild"? What |
| 16 |
> would happen without the revbump? |
| 17 |
|
| 18 |
Well, for completeness I'll start by listing what would happen with |
| 19 |
static deps. Though nothing will actually happen. Already-built |
| 20 |
packages may have the flag enabled along with deps. When people rebuild |
| 21 |
-- through --newuse, --changed-use or otherwise -- they will get |
| 22 |
the functionality and dependencies removed along with the flag. |
| 23 |
|
| 24 |
How dynamic-deps would handle that are pretty much a matter of |
| 25 |
implementation choice. I can think of two major possibilities: |
| 26 |
|
| 27 |
1. dynamic-deps are applied nevertheless. Since the relevant |
| 28 |
dependencies are removed along with the flag, dynamic-deps causes |
| 29 |
portage to no longer pull in needed libraries even though package was |
| 30 |
built with the flag enabled and still links to them. Long story short, |
| 31 |
linkage is broken. |
| 32 |
|
| 33 |
2. PM notices IUSE no longer matches and doesn't apply dynamic-deps. |
| 34 |
While this prevents the breakage from happening, it's one additional |
| 35 |
point to the list of cases when dynamic-deps are disabled. Which means |
| 36 |
that no further dependency changes to the ebuild have dynamic effect |
| 37 |
and -- with current portage implementation -- the dependencies are |
| 38 |
'reverted' to the state when the package was installed, even though |
| 39 |
just before the change portage used ebuild dependencies. |
| 40 |
|
| 41 |
Of course, you could try to invent some smart logic that would handle |
| 42 |
this specific case better. But it makes the dependency resolution even |
| 43 |
more complex and hard to understand, plus someone needs to actually do |
| 44 |
it. And then, you're going to hit even more corner cases and implement |
| 45 |
additional workarounds for each one. And then each of those workarounds |
| 46 |
will create new corner cases... |
| 47 |
|
| 48 |
-- |
| 49 |
Best regards, |
| 50 |
Michał Górny |
Archives