1 |
On Mon, 2021-06-28 at 15:00 +0200, Agostino Sarubbo wrote: |
2 |
> Hello all, |
3 |
> |
4 |
> long story short: |
5 |
> |
6 |
> when there is a major change (new gcc, new libc, and so on), tinderbox takes a |
7 |
> lot of time to test the entire tree. |
8 |
> |
9 |
> Let's do a practical example: |
10 |
> A new version of sys-devel/gcc is added to the tree. |
11 |
> |
12 |
> There is no way to know how much packages compiles C/C++ code, so the easiest |
13 |
> way is compile the entire tree. |
14 |
> |
15 |
> Instead, imagine that each ebuild declares a variable called SOURCETYPE ( or |
16 |
> similar, or in metadata.xml if you prefer ) and with a tool like equery/eix we |
17 |
> are able to get the list of all packages that compiles C code. |
18 |
> |
19 |
> The same thing applies to other languages like python, ruby, go and so on |
20 |
> where compile the dev-$language category covers a lot of packages, but there |
21 |
> will be always other ebuilds that uses $language in other categories. |
22 |
> |
23 |
> What do you think? |
24 |
> |
25 |
|
26 |
It's a worthwhile goal but it's practically impossible to get it right. |
27 |
For example, right now we've had quite a few cases of Python ebuilds |
28 |
wrongly declaring <stabilize-allarches/>, i.e. people missing use of C |
29 |
besides Python. |
30 |
|
31 |
That is, unless you can figure out a way for Portage to reliably detect |
32 |
SOURCETYPE and tell people what to set. |
33 |
|
34 |
-- |
35 |
Best regards, |
36 |
Michał Górny |