On Tue, Jul 22, 2014 at 4:06 PM, Martin Vaeth <mar...@mvath.de> wrote: > ...but by introducing all the additional complications Ian > has mentioned. More precisely: What happens if new dependencies > are introduced which are not satisfied? > One has to face it: Portage must not just silently "update" the > database and thus silently produce a /var/db which does not > satisfy its own dependencies...
While this is problematic, I think portage actually can handle this (but I haven't tested this recently). Portage already allows you to clean a package without its reverse deps leading to a system in exactly the state you describe. I believe portage will just try to bring the package back at the next emerge @world (or any other set containing the reverse dep). If there is a problem with the dependency version then the system is already broken anyway - portage just doesn't realize it. I think that allowing devs to instruct portage to update VDB with USE/dep/etc changes is potentially less problematic than having portage trying to guess what the right thing to do is. We could then either use that feature or revbump as appropriate under the specific circumstances. Ultimately I think the most important thing we need is for PMs to follow some kind of defined behavior. In our efforts to get portage to do the "right thing" we sometimes end up with a portage that does things that nobody really understands. Things like that tend to lead to convenience 95% of the time and head-banging the other 5%. I'm all for workarounds, but I'd advocate simple ones that lead to easily predicted behavior (and failure modes). I'd rather safely eliminate 70% of useless rebuilds than unsafely try to eliminate 90% of them. However, I do agree that we need to be sensitive to rebuilds. Rich
