about adding priority groups to the world set

[jeffss]

That is something I have been considering for some time, as it adds some more complexity for writing the dependency resolutions, however it may also significatively reduce complexity on the overall execution of merge operations, like world upgrades. The idea is that often anyway it is required to accept that some packages will break as a result of the resolutions, either it is too complicated to find a solution or there is not really some solution, so a way to add some organization could be to define that some packages are more acceptable to break then others, possibly also including a flag to turn on or off the consideration of that priority

[pingtoo]

I don't know how feasible to implementation, but totally agree and support this concept.

[Kangie]

[jeffss]

[jeffss]

maybe also some possibility for control could be using the symbol table, I mean that exposed from the "nm" command, for defining what could go wrong and if it can be allowed. For instance that emerge operation could be blocked if it would affect initialization for some packages but allowed if it relates to some auxiliary functions

[Hu]

Symbol table checks are not sufficient, and generally would help only if the affected packages are removing deprecated interfaces before their consumers have migrated to the new interface. This may happen, but the simple solution is to get the providing packages to keep the interfaces longer.

There is no need for a package to break its consumers. That only happens when the providing package's developers choose not to provide a clean migration path. If they choose not to do so, you cannot compensate for that lack with a more complicated dependency solver, because there is no valid path, no matter how clever the solver.

I think further discussion would require a more concrete example identifying what package(s) were a problem, why the manual fix worked (and the drawbacks it had), and from there we can discuss what a more clever solver could have done.

[jeffss]

[Hu]

You should never need to use --nodeps. --exclude only forbids emerge from installing the specified atoms. If they are required by some other change, excluding them will probably cause an error. You should instead solve the problem(s) that prevent you from installing them. There is no --ignore-rebuild. Did you mean you are ignoring slot operators? That too may cause new problems.

[jeffss]