On 28 July 2014 02:42, Rich Freeman <ri...@gentoo.org> wrote: > One thing I would question in that table is "applied immediately (but > can break hard when dynamic-deps stop working))." How can dynamically > removing an "unused dependency" cause something to break, setting > aside bugs in the package manager? If removing a dependency causes > something to break, how can it be "unused?" >
My apologies if this scenario has been explained before, I saw things along these lines, but must may have missed their point: I get the impression that this happens: 1. User installs Foo 2. Gentoo needs to change what Foo depends on 3. Gentoo simply tweaks the ebuild and doesn't bump [A] 4. User syncs. 5. Subsequent emerges see dependencies from [A] which are fixed and works in the interim 6. A gets removed. 7. User syncs. 8. Shadowing effect of [A] is removed, and Foo is now back depending on the wrong thing. =~ So although this problem will be resolved by also removing Foo, Foo still exists on the system with bad dependencies which could lead to some kind of problem, preventing emerge resolution from making sense. Sure, Foo will get reaped by a depclean if it is no longer in world and nothing depends on it, .... but depclean tends to require world to be deeply resolved first. And more questions for the -r1.1 style "Ship a new ebuild" style proposal. ::gentoo ships Foo-1.0 ::whatever *also* ships Foo-1.0 ( with different dependencies ) User installs from ::gentoo ::Whatever publishes a -r0.1 style ( or equivalent) dependency fix What happens for the user, and why. I'm of the mind ::Whatever should not tamper with ::gentoo here, though it could be useful, it could also prove problematic. Or maybe the idea is just too weird and quirky to implement this way. -- Kent *KENTNL* - https://metacpan.org/author/KENTNL
