1 |
On Sun, 2022-07-31 at 09:24 -0700, Georgy Yakovlev wrote: |
2 |
> Hello, |
3 |
> |
4 |
> Please reply with any topics you wish to be discussed during the next |
5 |
> council meeting (2022-08-14). |
6 |
> |
7 |
> Current default agenda: |
8 |
> 1. Roll call |
9 |
> 2. Open bugs with council participation |
10 |
> 3. Open floor |
11 |
> |
12 |
> - |
13 |
> Georgy |
14 |
> |
15 |
|
16 |
I would like to finalise the multilib transition started many years ago. |
17 |
Why am I asking for this? As a community, the question on how to handle |
18 |
multilib in Gentoo is a settled issue and we want a final determination |
19 |
for moving past previous proposals. To this end, I would want the |
20 |
council to rule on the following: |
21 |
|
22 |
1. Declare the current multilib solution (multilib-minimal.eclass, |
23 |
[${MULTILIB_USEDEP}] usedeps) the final _de facto_ and _de jure_ |
24 |
approach Gentoo has chosen to take with respect to the multilib problem. |
25 |
No other proposals will be entertained anymore. This does not affect the |
26 |
historically differing implementation in the toolchain. |
27 |
|
28 |
2. Portage-multilib is a dead end and doesn't have the manpower to |
29 |
remain viable. While the majority of the portage team supports this |
30 |
decision, I ask the council to give its blessing for ending Portage- |
31 |
multilib as a branch within the portage git repo. The branch should be |
32 |
removed, the author is free to maintain his fork going forward in a |
33 |
separate repo not associated with portage. |
34 |
|
35 |
3. Maintainers are free to close any bugs that are only reproducible |
36 |
with Portage-multilib as INVALID. |
37 |
|
38 |
Regards |
39 |
David |