Ciaran McCreesh wrote: > Uh huh, so you add an overlay, and suddenly the dependencies for a > random subset of your installed packages change in ways that don't in > any way reflect what you have installed. How is this the desired > behaviour?
There are several different cases of dependency data which apply in different ways for different operations. For a model to be accurate it needs to consider all cases, and treat them differently where neccessary. Adding an overlay doesn't change anything about what is installed. Installing one version of an ebuild from an overlay, with another version of the ebuild (from same overlay, or not) already installed, clearly needs the package manager to consider what the overlay ebuild says. That's the purpose of the overlay. Overlay maintainers already have the responsibility to create well-formed ebuilds, and there are even tools like overlint to help with the task. If they don't, the applicability of their overlay decreases. Sometimes this is on purpose, and it can be completely unproblematic. It's a little like rewriting public git history. Many people cry bloody murder about that, but in lots of cases it's perfectly fine. So are overlay dependencies which aren't perfectly well-formed. That's probably why they're in an overlay in the first place. It's not the responsibility of the package manager to magically resolve dependencies without sufficient information. It's the responsibility of ebuild authors to provide such information, so that dependencies can be resolved accurately for all package manager operations. It seems that this may be a case of trying to do way too much, and as a result doing a bad job at everything. I agree firmly with Rich that it is much better to do a good job at some (well-known, perhaps even documented) things, than a bad job at all things. It's fine to simply error out with a message saying that the encountered situation is not supported. //Peter
pgpGNpzVh0wY0.pgp
Description: PGP signature
