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