Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: >> User installs foo-1.1-r1 >> Developer makes foo-1.1-r2 >> foo-1.1* is removed from the tree >> User syncs >> >> In fact, the result is completely the same
You completely ignored this essential point: The result is completely the same, and you are just arguing with a strawman. But, OK, so I will use your strawman to prove how static deps are broken: >> What is *actually* broken here is that the user >> has installed a package which is not maintained >> anymore: *This* is what needs to be fixed. > > Uhm. That works just fine... Not at all: 1. Some package depending on foo/bar is removed, but the user keeps it, since deps are stored in /var/db. 2. foo/bar is split into foo/bar-A foo/bar-B for whatever reasons. Of course, all maintained ebuilds fix the dependency, and let us assume they are even revbumped. 3. The orphaned package of course still depends on installed foo/bar, causing all sort of blockers. 4. The user has no way for fixing the issue than in modifying /var/db manually. He cannot even put an ebuild into his overlay and only modify this ebuild and the metadata, because the PM dumbly insists on using only the (broken and outdated since ages) information in /var/db > I don't think you understand how this works: Quite the opposite: I see that it fixes many issues. It has also some issues with orphaned packages, but *every* approach will have issues with orphaned packages.
