| 1 |
On Thursday, October 27, 2016 09:21:06 AM Rich Freeman wrote: |
| 2 |
> On Thu, Oct 27, 2016 at 9:07 AM, Michael Mol <mikemol@×××××.com> wrote: |
| 3 |
> > I want to +1 this, but I do see one problem: If all dependencies are |
| 4 |
> > defined, how does "emerge --with-bdeps=y --emptytree @world" work? |
| 5 |
> > Defining all 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 |
| 24 |
> > newest 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 |
So, what goes in @stage1? What's the bare minimum needed for a Gentoo package |
| 40 |
kernel? |
| 41 |
|
| 42 |
-- |
| 43 |
:wq |
Archives