| 1 |
On Tue, 2013-05-28 at 12:52 -0400, Rick "Zero_Chaos" Farina wrote: |
| 2 |
> On 05/28/2013 12:42 PM, Brian Dolbec wrote: |
| 3 |
> > On Tue, 2013-05-28 at 00:34 -0400, Rick "Zero_Chaos" Farina wrote: |
| 4 |
|
| 5 |
> > I have 3 reasons for wanting this change done this way |
| 6 |
> > |
| 7 |
> > 1. If a spec or config enables the PKGCACHE option. It will add |
| 8 |
> > all the binpkg options to the emerge command. Due to the |
| 9 |
> > possible problem with using/creating binpkgs during the |
| 10 |
> > update_seed process. These options should not be set. Currently |
| 11 |
> Can you please describe how using binpkgs during update_seed is an |
| 12 |
> issue? I don't think all of us fully understand that, I know I don't. |
| 13 |
|
| 14 |
This was all discussed in irc and the catalyst list. But somehow you |
| 15 |
seemed to miss it all. |
| 16 |
|
| 17 |
Early this year, mpc had an updated version. |
| 18 |
The existing update_seed command: |
| 19 |
|
| 20 |
clst_root_path=/ run_merge "--buildpkg=n --update --deep --newuse |
| 21 |
--onlydeps gcc" |
| 22 |
|
| 23 |
updated mpc, consequently, libmps.so,2 was deleted. libmpc.so.3 was |
| 24 |
created. This broke the existing gcc pkg due to the missing lib. |
| 25 |
This means that gcc needs to be rebuilt in order to be linked to |
| 26 |
libmpc.so.3. The existing command excluded gcc from being built (the |
| 27 |
opposite to what is needed). This failure in gcc did not show up until |
| 28 |
stage2 I believe, and was a bit troublesome to pin down the cause. |
| 29 |
|
| 30 |
Which is why I changed that line to: |
| 31 |
|
| 32 |
clst_root_path=/ run_merge "--update --deep --newuse --complete-graph |
| 33 |
--rebuild-if-new-ver gcc" |
| 34 |
|
| 35 |
It may be slightly overkill with the --deep --complete-gragh but it |
| 36 |
removes potential problems in revdep-rebuild, so... |
| 37 |
|
| 38 |
NOW for how binpkgs play into this. |
| 39 |
|
| 40 |
Existing gcc binpkgs have been linked to libmpc.so.2 and portage does |
| 41 |
not check that all lib links exist before qualifying the binpkg to be |
| 42 |
installed. Therefore installing a gcc binpkg is a hit and miss |
| 43 |
proposition. Making it's use un-reliable. Therefore until the |
| 44 |
toolchain is migrated to eapi 5 with proper subslot use. Using binpkgs |
| 45 |
is unreliable for update_seed. |
| 46 |
|
| 47 |
While this may slow down the stage1 process some. It does make it more |
| 48 |
reliable, so that the releng team won't be wasting time tracking down |
| 49 |
errors that can be otherwise prevented. Binpkgs can be created and |
| 50 |
reused with some caution for the regular stage build. But some errors |
| 51 |
may similarly occur if the snapshot used is changed between runs without |
| 52 |
clearing or checking existing binpkgs. Again eapi 5 pkg migration will |
| 53 |
solve this. Hence the user beware warning. |
| 54 |
|
| 55 |
|
| 56 |
> > Also I have slightly different PKGCACHE options in my rewrite branch. I |
| 57 |
> > have added --binpkg-respect-use to them. It was brought to my attention |
| 58 |
> > early in testing to put them in a config to eliminate the problem of |
| 59 |
> > using binpkgs that were not compiled with them set correctly. |
| 60 |
> We should probably make this default, if everyone agrees I can drum up a |
| 61 |
> quick patch and add it. This is already default in my profile to |
| 62 |
> infinite success. |
| 63 |
> |
| 64 |
> thanks, |
| 65 |
> Zero |
| 66 |
> > |
| 67 |
It was you that told me about that option, which is why i added it as |
| 68 |
default when PKGCACHE is enabled. |
| 69 |
That is something that Jorge did not pick up in my proposed patch. I do |
| 70 |
not know why. Nothing was said as I recall. |
| 71 |
-- |
| 72 |
Brian Dolbec <dolsen@g.o> |
Archives