On Sun, Jul 27, 2014 at 5:17 PM, Michał Górny <[email protected]> wrote: > Dnia 2014-07-27, o godz. 17:08:27 > Rich Freeman <[email protected]> napisał(a): >> >> I'd think that portage should update vdb as soon as it detects the >> dependency change. Then B would no longer depend on A in vdb. It >> shouldn't hold onto outdated information. > > You just introduced the opposite breakage -- when a dependency on C was > added, it ends up in vdb before C is installed. Now if C and current > version of A are removed before C gets installed, you end up having > broken dependency in vdb. >
There is a possibility that you had the broken dependency before you even synced - you just didn't realize it yet. After all, if the dep was added only as the result of an actual on-disk change, there should have been a revbump. So, having a missing dep in vdb just makes vdb reflect reality. You can get a missing dep in vdb by unmerging a package without using depclean. An unmet dependency is still a dependency. > Plus, 'as soon' means you're making --pretend actually write something. > That's bad. This isn't all that different from package moves. I believe that modifies vdb as soon as it detects updates. There is the issue of syncing and then not updating and then having all the packages removed from the tree - you're then missing a package and have no easy way to install it. But, in that case you can put the necessary ebuilds into your overlay and then portage can make everything right. Rich
