On Thu, Oct 27, 2016 at 9:07 AM, Michael Mol <mike...@gmail.com> wrote: > > I want to +1 this, but I do see one problem: If all dependencies are defined, > how does "emerge --with-bdeps=y --emptytree @world" work? Defining all > dependencies means the graph is completely cyclic.
Well, we'll need to define some kind of stage1 set no matter what we do because of the bootstrapping problem. Perhaps this can be leveraged when breaking cyclical dependencies (optimize as much as you can, allow parallel builds, but do the stuff in the stage1 set first and don't treat circular deps as show-stoppers). And I don't think portage actually breaks today with circular deps as long as some start out satisfied. If a depends on b and b depends on a, and both have an upgrade, but the dependencies are unversioned, then I think portage just does them in arbitrary order. Now, if both have circular versioned dependencies and you don't have at least one installed, you're stuck (maybe a really clever portage might find earlier intermediate versions with relaxed dependencies that break this cycle, but I'd be surprised if that works today). > Perhaps the answer is that it doesn't; you have to run 'emerge --emptytree > @world twice' if you want to ensure every package is rebuilt with its newest > available build dependencies. Well, if your goal is completely consistent rebuilds you can't avoid the need to rebuild the stage1 set twice because of the bootstrapping problem (which I believe is why we have stage2). A solution would be to first emerge the stage1 set, then do the emerge @world. However, in practice I don't think there are many situations where you really need to do a rebuild of this scale. I'm not saying you can completely avoid the need for having some kind of bootstrapping stage1. I'm just saying we should separate that need from the issue of fully specifying dependencies, at least in an ideal world where we're unconcerned with the effort of specifying dependencies. -- Rich
