| 1 |
Hi |
| 2 |
|
| 3 |
28.06.2021 14:00, Agostino Sarubbo пишет: |
| 4 |
> Hello all, |
| 5 |
> |
| 6 |
> long story short: |
| 7 |
> |
| 8 |
> when there is a major change (new gcc, new libc, and so on), tinderbox takes a |
| 9 |
> lot of time to test the entire tree. |
| 10 |
> |
| 11 |
> Let's do a practical example: |
| 12 |
> A new version of sys-devel/gcc is added to the tree. |
| 13 |
> |
| 14 |
> There is no way to know how much packages compiles C/C++ code, so the easiest |
| 15 |
> way is compile the entire tree. |
| 16 |
> |
| 17 |
> Instead, imagine that each ebuild declares a variable called SOURCETYPE ( or |
| 18 |
> similar, or in metadata.xml if you prefer ) and with a tool like equery/eix we |
| 19 |
> are able to get the list of all packages that compiles C code. |
| 20 |
> |
| 21 |
> The same thing applies to other languages like python, ruby, go and so on |
| 22 |
> where compile the dev-$language category covers a lot of packages, but there |
| 23 |
> will be always other ebuilds that uses $language in other categories. |
| 24 |
> |
| 25 |
> What do you think? |
| 26 |
> |
| 27 |
> Agostino |
| 28 |
> |
| 29 |
> |
| 30 |
|
| 31 |
I can easily imagine a scenario where some pure perl package would fail |
| 32 |
tests because one of indirect dependencies was compiled with clang |
| 33 |
instead of gcc. |
| 34 |
|
| 35 |
-- |
| 36 |
Best regards, |
| 37 |
Alexey "DarthGandalf" Sokolov |
Archives