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