On Thu, Nov 13, 2014 at 5:30 AM, Michael Palimaka <kensing...@gentoo.org> wrote: > > In general, a package must explicitly depend upon what it directly uses. > However, to avoid ebuild complexity and developer burden there are some > exceptions. Packages that appear in the base system set may be omitted > from an ebuild's dependency list in the following circumstances: >
So, I'm not a big fan of implicit dependencies in general. What does the new policy buy us that the existing one does not? Why not try to find a way to ditch implicit dependencies entirely? If the issue is that nobody wants to have a laundry list of dependencies in every package, why not use something like a virtual to pull in all the commonly-used stuff. Then for the 0.1% of the tree where it matters we could list things explicitly so that we don't have a big pile of packages that portage can't parallelize. It seems like the problems with the current approach are: 1. @system can vary by profile, which allows bugs to creep in since maintainers can't stay on top of what is and isn't always in @system). 2. PMs can't build @system packages in parallel, since it doesn't know what the real deps are. 3. The way we use @system makes it hard to tell if it is safe to remove some package which is otherwise heavily-used. You never really know if you can safely do without bash, and so on. (Note, this bit wouldn't be helped at all by simply turning system into a big virtual.) I'm not entirely sure what problem you're trying to solve, so the above may or may not be helpful. I'm fine with incremental improvements if they actually improve something. Otherwise, the status quo does have the benefit of simplicity - you don't have to list @system packages as dependencies ever, but you can do so if you wish or it brings some benefit (deps on specific versions/slots, slot-operator deps, etc). -- Rich
