1 |
On Mon, 30 Jan 2017 14:04:06 -0600 |
2 |
William Hubbs <williamh@g.o> wrote: |
3 |
|
4 |
> As I said on the bug, the downside is the addition of py3 and ninja as |
5 |
> build time dependencies, but I think the upside (a build system where |
6 |
> we don't have to worry about parallel make issues or portability) |
7 |
> outweighs that. |
8 |
|
9 |
On principle I would discourage this course of action. |
10 |
|
11 |
Critical infrastructure should be built on proven and established technology |
12 |
that has practically become boring to the point of almost-stagnation. |
13 |
|
14 |
Building things atop of newer technology ends up being like building upon |
15 |
shifting sands. |
16 |
|
17 |
And all this is doubly important if you're ever needing to bootstrap. |
18 |
|
19 |
ie: It might be justifiable to build openrc on top of meson on an established |
20 |
system which already has a working openrc, but building openrc on meson |
21 |
when you're installing your first Gentoo install is going to be much more painful |
22 |
than it should be. |
23 |
|
24 |
And we should be keeping the @system essentials set required for new installations |
25 |
to be as minimal as possible without losing functionality. |
26 |
|
27 |
And here, I think the objectives of being parallel-make friendly are small |
28 |
in compare with the overhead for ensuring the dependencies are present and working |
29 |
and usable on a clean install. |
30 |
|
31 |
But a package that has only been in tree a measly 7 months seems far, far |
32 |
too premature to switch to being a mandatory part of the critical path. |