| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On 05/28/2013 01:59 PM, Brian Dolbec wrote: |
| 5 |
> On Tue, 2013-05-28 at 12:52 -0400, Rick "Zero_Chaos" Farina wrote: |
| 6 |
>> On 05/28/2013 12:42 PM, Brian Dolbec wrote: |
| 7 |
>>> On Tue, 2013-05-28 at 00:34 -0400, Rick "Zero_Chaos" Farina wrote: |
| 8 |
> |
| 9 |
>>> I have 3 reasons for wanting this change done this way |
| 10 |
>>> |
| 11 |
>>> 1. If a spec or config enables the PKGCACHE option. It will add |
| 12 |
>>> all the binpkg options to the emerge command. Due to the |
| 13 |
>>> possible problem with using/creating binpkgs during the |
| 14 |
>>> update_seed process. These options should not be set. Currently |
| 15 |
>> Can you please describe how using binpkgs during update_seed is an |
| 16 |
>> issue? I don't think all of us fully understand that, I know I don't. |
| 17 |
> |
| 18 |
> This was all discussed in irc and the catalyst list. But somehow you |
| 19 |
> seemed to miss it all. |
| 20 |
> |
| 21 |
> Early this year, mpc had an updated version. |
| 22 |
> The existing update_seed command: |
| 23 |
> |
| 24 |
> clst_root_path=/ run_merge "--buildpkg=n --update --deep --newuse |
| 25 |
> --onlydeps gcc" |
| 26 |
> |
| 27 |
> updated mpc, consequently, libmps.so,2 was deleted. libmpc.so.3 was |
| 28 |
> created. This broke the existing gcc pkg due to the missing lib. |
| 29 |
> This means that gcc needs to be rebuilt in order to be linked to |
| 30 |
> libmpc.so.3. The existing command excluded gcc from being built (the |
| 31 |
> opposite to what is needed). This failure in gcc did not show up until |
| 32 |
> stage2 I believe, and was a bit troublesome to pin down the cause. |
| 33 |
> |
| 34 |
> Which is why I changed that line to: |
| 35 |
> |
| 36 |
> clst_root_path=/ run_merge "--update --deep --newuse --complete-graph |
| 37 |
> --rebuild-if-new-ver gcc" |
| 38 |
> |
| 39 |
> It may be slightly overkill with the --deep --complete-gragh but it |
| 40 |
> removes potential problems in revdep-rebuild, so... |
| 41 |
> |
| 42 |
> NOW for how binpkgs play into this. |
| 43 |
> |
| 44 |
> Existing gcc binpkgs have been linked to libmpc.so.2 and portage does |
| 45 |
> not check that all lib links exist before qualifying the binpkg to be |
| 46 |
> installed. Therefore installing a gcc binpkg is a hit and miss |
| 47 |
> proposition. Making it's use un-reliable. Therefore until the |
| 48 |
> toolchain is migrated to eapi 5 with proper subslot use. Using binpkgs |
| 49 |
> is unreliable for update_seed. |
| 50 |
|
| 51 |
In fact, the command is "--rebuild-if-new-ver" not |
| 52 |
"--reinstall-if-new-ver". As such, the original reporter of this bug |
| 53 |
and I both seem to think that even with --usepkg, gcc should be rebuilt: |
| 54 |
|
| 55 |
https://bugs.gentoo.org/show_bug.cgi?id=461422 |
| 56 |
|
| 57 |
That's obviously not how it is, but I feel we should focus our attention |
| 58 |
on fixing this properly. |
| 59 |
> |
| 60 |
> While this may slow down the stage1 process some. It does make it more |
| 61 |
> reliable, so that the releng team won't be wasting time tracking down |
| 62 |
> errors that can be otherwise prevented. Binpkgs can be created and |
| 63 |
> reused with some caution for the regular stage build. But some errors |
| 64 |
> may similarly occur if the snapshot used is changed between runs without |
| 65 |
> clearing or checking existing binpkgs. Again eapi 5 pkg migration will |
| 66 |
> solve this. Hence the user beware warning. |
| 67 |
|
| 68 |
As a rule, we don't want to hack around limitations in portage to make |
| 69 |
catalyst work. The toolchain team seems to have made it very clear they |
| 70 |
aren't updating to eapi5 soon, but the portage team has been fixing |
| 71 |
things left and right based on little more than my whims, I'd give them |
| 72 |
a chance to fix this before throwing hacks into catalyst to work around |
| 73 |
limitations in the package manager. |
| 74 |
|
| 75 |
Thanks, |
| 76 |
Zero |
| 77 |
> |
| 78 |
> |
| 79 |
>>> Also I have slightly different PKGCACHE options in my rewrite branch. I |
| 80 |
>>> have added --binpkg-respect-use to them. It was brought to my attention |
| 81 |
>>> early in testing to put them in a config to eliminate the problem of |
| 82 |
>>> using binpkgs that were not compiled with them set correctly. |
| 83 |
>> We should probably make this default, if everyone agrees I can drum up a |
| 84 |
>> quick patch and add it. This is already default in my profile to |
| 85 |
>> infinite success. |
| 86 |
>> |
| 87 |
>> thanks, |
| 88 |
>> Zero |
| 89 |
>>> |
| 90 |
> It was you that told me about that option, which is why i added it as |
| 91 |
> default when PKGCACHE is enabled. |
| 92 |
> That is something that Jorge did not pick up in my proposed patch. I do |
| 93 |
> not know why. Nothing was said as I recall. |
| 94 |
> |
| 95 |
|
| 96 |
-----BEGIN PGP SIGNATURE----- |
| 97 |
Version: GnuPG v2.0.19 (GNU/Linux) |
| 98 |
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ |
| 99 |
|
| 100 |
iQIcBAEBAgAGBQJRpPyQAAoJEKXdFCfdEflKM1oQALB5UV+N2Qeou3MVRuW4vx4w |
| 101 |
88yHebh8Vm2wihhIk8iJeoUw05uHTpu6DlTcO0f7cjpqRpTc61ULYss+/YWFVbGv |
| 102 |
PIB7uRquQv/aDFkfctSuUEYsVN94HmHB23T+tKHUPoGNWbmggvu4Y/z2nGAP6cNK |
| 103 |
WbXx+6qvpMLK5LqN9+y9QB5Ml3of02i4brs1r42wUFxp6u/A4usuMq7s4hIoHUAh |
| 104 |
RlxOIZPUCLxUV8BNNqsKsEOxFEZyawBnVAhUrp9C/GX4BvqsMeeT1R9KtgCjmcFI |
| 105 |
lBtmyu4PVOUe/uBvfJd6CS3zpyx8ZY3/+BJzSEX7kB9ael2Ejg1JtGJFxQIC1RbL |
| 106 |
/ctK2PBmiJ4BTGvzYN9HkgSqvsv6K+0IIsV2450oKd+CoyEeQ1M+Nj2NODVs+Io3 |
| 107 |
i3YyVDyZZzRqphdB8RBDLrrQ0ADuA9kRWNWTffaqla5l5pcdZs9EH87Kbvue2fZw |
| 108 |
ISe50Bc1RPKePrhRthcP3OgaelU3YALDwOD2Apt+VGFAEmlByqwU2biqSXs6L/5v |
| 109 |
zbPlvazqFjBPqDpJclIc8ETNUSqP5ODN2KesmZVd0pOSIsyDOjZoZL++HzRqtSrO |
| 110 |
+vtRDXAq1kpFS25Frbd5yDbNQm+Qm9dVOWm6WJuG6kPwOW2AuI1m0lABFobo0nSr |
| 111 |
NApls/UNICUhjIGZQsKZ |
| 112 |
=5YP8 |
| 113 |
-----END PGP SIGNATURE----- |
Archives